[quotemstr]

> It's also worth reading through the POSIX manpages for POSIX sh if you want to be a good shell scripter.

Or you can give the middle finger to POSIX, write shell scripts for bash, or even zsh, and end up with faster, more correct, and more beautiful shell scripts that in practice are just as portable as the ones that mindlessly follow the limited and bizarre POSIX shell spec.

I'll write POSIXly-correct shell scripts when the POSIX people stop pretending it's still 1995.

[adrian_b]

Actually, regarding shells, the POSIX people pretend that it is still 1988.

The POSIX shell is the Bourne shell (1979) plus half of the innovations brought by ksh88.

The other half of the improvements from ksh88 and all of the improvements from ksh93 are not included in the POSIX shell standard.

Also for POSIX compliant shells one must not forget that also the other programs invoked by the shell must not be used with non-POSIX options.

For example, in a bash script I used the ksh93 syntax:

  ${VARIABLE:64:32}

Then I wanted to make it POSIX compliant and I rewrote it in the longer:

  $(expr substr "${VARIABLE}" 65 32)

But then I discovered that POSIX expr lacks substr, so I had to rewrite the expression into the even longer:

  $(awk -v s="${VARIABLE}" 'BEGIN {print substr(s, 65, 32)}')

which is the only POSIX compliant way to extract substrings.

In most cases the rational way is to write scripts for bash or zsh, which include all the ksh93 features plus brace expansion (from csh, then enhanced by zsh).

Writing POSIX compliant scripts results in much longer scripts in which the chances of bugs are much higher.

[Woodi]

> Or you can give the middle finger to POSIX

Ok, pleas someone tell me how to use that "upvote" festure on HN :)

More on the subject, nor type nor command, nor constantly mentioned shellcheck recipe for all posixs actually do what which do - just returns path ! Looks like with some options, maybe, but it could be simply added with "which -h" - (standard *nix human readable form toggle), if -h is not already taken.

POSIX in the first place should just standarise which instead of inventing some "command".

Advice: to write best POSIX scripts write moustly-POSIX scripts and be done. Simply becose you should write big shell scripts in the first place. It is Perl job and it do it very better. And if you want more you need C and actually using system calls yourself, eg. for precise path not-globbing.

PS. Now just wait for Mr Poettering take on the subject becouse why be bothered by decades old working admins opinions or work conditions ? Or usable standards, or already working code, or not containers use cases, or just short, human friendly commandline ? Or not tangled and small codebases ?? Let's leave it to, I don't know, IBM ? Is systemd portable to AIX yet, any plans ? ;) WINDOWIZACION95 FTW

[Seirdy]

You're free to do this, but be aware that you'll then need to be aware of where your scripts will and won't run.

I regularly use Fedora, Alpine Linux, Void, Debian, and OpenBSD. Void uses dash as its default shell, Debian uses it as /bin/sh but still includes bash, OpenBSD uses another POSIXy shell, Fedora uses Bash. macOS also uses zsh as /bin/sh.

If you want portability, you don't have much of a choice. Devs not caring about portability is why less common operating systems are a struggle to use which only fuels monocultures.

Standards compliance and implementation diversity have a symbiotic relationship that is necessary for the health of open platforms. I described the benefits in more detail in a blog post:

https://seirdy.one/2021/02/23/keeping-platforms-open.html

[account42]

If your shell scripts are complex enough for you to be limited by POSIX then they probably shouldn't be shell scripts in the first place.