[jlokier]

> /usr/bin/env and /bin/sh are part of the POSIX standard, this is why NixOS has those available.

Contrary to popular belief, those aren't in the POSIX standard.

The following are not in the POSIX standard, they are just widely implemented:

  - "#!" line.
  - /bin/sh as the location of a POSIX compliant shell, or any shell.
  - /usr/bin/env as the location of an env program.
  - The -S option to env.

[Guvante]

I think you are using "not required by the POSIX standard" when you say "not in" which is not an accurate shorthand.

#! is certainly in the POSIX standard as the exact topic of "is /bin/sh always a POSIX" shell is a discussion point (it is not guaranteed since there were systems that existed at the time that had a non-POSIX shell there)

[johnisgood]

Are they in POSIX? I do not think they are. All of them is a convention from what I remember.

Shebang is a kernel feature, for example, and POSIX does define the sh shell language and utilities, but does not specify how executables are invoked by the kernel.

Similarly, POSIX only requires that sh exists somewhere in the PATH, and the /bin/sh convention comes from the traditional Unix and FHS (Filesystem Hierarchy Standard), but POSIX does not mandate filesystem layout.

... and so on.

Correct me if I am wrong, perhaps with citations?

[wahern]

You're definitely correct. "#!" is reserved (see Rationale C.2.1), but not required, though it's described as "ubiquitous" (see Rationale C.1.7). "/bin/sh" isn't required either, but arguably ubiquitous in that there's always some shell located there. The proper way to find the POSIX-conformant shell is with `command -v sh` (which is equivalent to using `getconf PATH` and then searching for sh), and POSIX counsels to discover the path and substitute it inline when installing scripts (see Application Usage in sh utility specification.)

IME /bin/sh is invariably sufficiently POSIX conformant to bootstrap into a POSIX shell (or your preferred shell), even on Solaris and AIX. And if you're willing to stick to simple scripts or rigorously test across systems, sufficient for most tasks. Outside Linux-based systems it's usually ksh88, ksh93, pdksh, or some derivative. OTOH, for those who are only familiar with bash that may not be particularly helpful.

I've had more trouble, including bugs, with other utilities, like sed, tr, paste, etc. For shell portability it's usually niche stuff like "$@" expansion with empty lists, for example how it interacts with nounset or IFS, independent of POSIX mode.