> C99 isn’t a compiler.

Sure, but the pojt here is that if we say "Write in X" we generally understand it to mean "Treat X like a standard and don't get too colloquial with the stylings."

Pedantry is worthwhile, but it can be a diminishing returns game.

▲

eqvinox 9 hours ago | parent [-]

Feels like you missed the point.

On the example of 'echo \n' - it's not defined in POSIX, therefore a script written in "POSIX shell" must simply never hit that case.

TFA kinda implies you can't target POSIX shell. That's silly, of course you can. The question is, what tools are there to check for compliance. Whether running on 14 shells is a good such tool - idk. Something specifically searching for POSIX violations might be better.

▲

Joker_vD 9 hours ago | parent | next [-]

Well, with C language it's pretty much the same. You are supposed to "just" never write (or rather, most of the time, to just not execute) anything that is UB. And lots and lots of people to this day continue to believe that can do this (most of the time, they're wrong).

	▲	eqvinox 8 hours ago \| parent [-]
		UB (specified to be undefined) and 'plain' unspecified are not the same thing.

▲

gaigalas 9 hours ago | parent | prev [-]

The spec is not that good.

`local` for example is present in many shells (almost all of them), but they decided to leave it out uniquely because of ksh93 (scope is different). It became undefined behavior.

When the spec was written, ksh was important. Since then, it has only been revised but not updated and I consider it to be obsolete.

So, if you follow POSIX strictly, you then lose local scope on functions, which is more likely to cause bugs and hard to catch with a linter like you suggested. You're left with a broken feature set (on many other angles too) that is not actually practical. Even spellcheck makes concessions.

▲

NekkoDroid 3 hours ago | parent | next [-]

The simple fact that POSIX doesn't define any long options for basically any CLI tools just makes me outright ignore it when writing scripts.

I use long options in scripts so that you can actually understand which options are used. Short options are for interactive shells since those commands nobody is really gonna look at again.

	▲	gaigalas 2 hours ago \| parent [-]
		That is another can of worms. For now, I'm worried only about the shell interpreter and builtins. `echo` in most shells is not `/bin/echo`, it's actually an internal implementation (external echo means forking at every output, which is super slow). The portability of other cor utils is also a clown fiesta, and most likely the best solution for now is "use gnu", which sometimes feels like "best viewed in internet explorer"-era shinenigans.

▲

echoangle 9 hours ago | parent | prev [-]

I don’t get this point either. If local is not in the POSIX spec, I guess you can’t use it if you want to be POSIX compatible. Just because many shells do it doesn’t mean it’s POSIX.

▲

gaigalas 9 hours ago | parent [-]

You can target POSIX if you want to, but doing that doesn't guarantee shell scripts will work.

The blog post stresses this, the difference between POSIX and portability.

If you want portability, testing is better for now. One of the goals of these projects is to more precisely capture a retrospec (what actually works, not what was specified), it's the same thing they did with HTML5.

	▲	echoangle an hour ago \| parent [-]
		> but doing that doesn't guarantee shell scripts will work. How so? Can you give an example that should work according to the POSIX spec but doesn’t in a POSIX compliant shell? The example in the post is just some behavior the POSIX spec doesn’t specify, so obviously you wouldn’t be allowed to do that when targeting POSIX.