Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Inconsistent: claims /bin/sh on Alpine is dash in one paragraph, BusyBox ash in another.
Smells a lot of AI writing.
by croemer - > POSIX is a specification. Not a program. The thing that actually runs your script is bash, dash, ash, ksh, yash, or one of a dozen others. They each implement POSIX with their own gaps, extensions, and historical accidents.
Blaming POSIX, because a program does not implement it, is childish.
by hulitu - The author has neglected the pdksh family of shells which includes all of Android, so this is a sizable oversight.
This would include the MirBSD mksh, and oksh from OpenBSD.
They are much smaller than ksh93 and bash, and I would suggest that their syntax extensions be given preference, as they originally represented ksh88 (from which the POSIX shell standard was derived).
by chasil - This is quite a timely post compared to: https://bower.sh/posix-shell-is-all-you-need
This post was thought provoking, I wonder, is the hidden argument here that the posix spec for a shell is not well specified if there is so much variance between the implementations?
Or is the fundamental issue simply a matter of history? Both?
by qudat - FWIW Oils has an option to prevent the ambiguity:
It really should beosh-0.37$ echo "c:\new" c:\new osh-0.37$ shopt --set no_parse_backslash osh-0.37$ echo "c:\new" echo "c:\new" ^ [ interactive ]:6: Invalid char escape in double quoted string (OILS-ERR-12)
That is an unambiguous program that works in every shell. In a well-written shell program, the only things that should follow a single backslash in a double quoted string areecho "c:\\new" # with two backslashes
(Although I found that this option is only on in ysh, not in shopt --set strict:all ... arguably that should be changed)\ " ` $Nine Reasons to Use OSH - https://oils.pub/osh.html
by chubot - Stéphane Chazelas would agree,
* https://unix.stackexchange.com/a/496642/5132
because the problem here is educating people with slipshod ideas about 'sh' being 'the POSIX shell' or (worse) 'the Bourne shell'. Both M. Chazelas and M. Gaigalas are making the point that 'sh' is a language that one aims to write in, not one of the many programs that sort of, sometimes, if invoked in the right way, implement that language; and a subordinate point that people are generally very poor about doing that when yet they insist that they are writing 'POSIX shell script'.
Fun facts: Standardization led by existing practice is not a simple process.
* https://unix.stackexchange.com/a/493743/5132
POSIX/SUS standardization is not a static thing. The long discussed thorny issue of echo has now subtly changed from all of those explanations given about it over the years, because in 2024 the standard was changed.
* https://pubs.opengroup.org/onlinepubs/9799919799/utilities/e...
M. Chazelas's own quite famous 2013 StackExchange answer on the subject has not yet been updated with the change that now incorporates -e and -E into the rule. Amusingly, it was M. Chazelas that raised defect 1222 that caused this change.
by JdeBP - Pretty bad argument. If it’s not defined by POSIX, it’s not POSIX compatible if you rely on a specific behavior.
If you only use defined behavior and it works, it is compatible.
It’s like saying C99 isn’t a compiler. True, but you can still write C99 code, right?
by echoangle - This post is nice: the writer first explains a problem, using a simple example. In the next section, they reflect a bit about the problem, and then they casually mention two tools they built. In my opinion, this is amazing: you sponsor you project, while also making the problem it solves clear: use their tool to test how portable your code isby Muhammad523