4 ms·

POSIX does not specify the path of anything. It says that "sh" is a shell, but doesn't say that "/bin/sh" is that shell. See: https://pubs.opengroup.org/onlinep

POSIX does not specify the path of anything. It says that "sh" is a shell, but doesn't say that "/bin/sh" is that shell. See: https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ I believe that in Solaris before Solaris 10, /bin/sh was the original Bourne shell (which didn't comply with POSIX), and in Solaris 10 it's ksh (which isn't either, but is way closer): https://unix.stackexchange.com/questions/538844/does-posix-guarantee-the-paths-to-any-standard-utilities https://unix.stackexchange.com/questions/538844/does-posix-g... Also, I don't think that "#!" is specified in POSIX. It's extremely common, it's just not in the specification. This is similar to find's "-print0" option, which also isn't in the POSIX specification but basically everyone implements it. If you want a specification of "where things go", the closest one in practice (and one that most modern distributions try to follow) is the Filesystem Hierarchy Standard (FHS): https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

deleted 7y ago
[deleted]
LukeShu 7y ago
(providing more detailed references) POSIX specifically calls out that it doesn't guarantee that the path is "/bin/sh": 107271 Applications should note that the standard PATH to the shell cannot be assumed to be either 107272 /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by 107273 getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell 107274 built-in. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s... POSIX mentions "#!" several times, but doesn't require it; saying things like "on systems that support executable scripts (the "#!" construct)". As the lack of a hard-codable path is frustrating, it recommends setting the shebang at install-time: 107279 Furthermore, on systems that support executable scripts (the "#!" construct), it is 107280 recommended that applications using executable scripts install them using getconf PATH to 107281 determine the shell pathname and update the "#!" script appropriately as it is being installed 107282 (for example, with sed). For example:
JdeBP 7y ago
As I wrote at https://unix.stackexchange.com/a/567405/5132 https://unix.stackexchange.com/a/567405/5132 , I have a strong suspicion that Arch Linux dropping the FHS is the tipping point, and adherence to the FHS is now the exception not the norm.
- squiggleblaz 7y ago
  Why would Arch dropping the FHS be the tipping point? Surely Arch represents hackers and not mainstream Linux users. In much the same way I wouldn't cite Linux users are a tipping point in any computer system convention (but Mac OS or Android or Windows), I wouldn't cite Arch in a Linux system convention (but Debian or Ubuntu or Red Hat). Why do you consider Arch as the tipping point?
  - JdeBP 7y ago
    Because it would be, if my suspicion proves to be the case, the point where adherence to the FHS tips over from being the norm to the exception. MacOS, Windows, and who Arch users are have nothing to do with it. How many distribution creators have made each of the various choices, does. Arch's decision to use systemd had some influence (in both directions, c.f. Hyperbola Linux). Arch's decision to abandon the FHS in favour of the systemd file-hierarchy may well do likewise.

deleted 7y ago

[deleted]

LukeShu 7y ago

(providing more detailed references) POSIX specifically calls out that it doesn't guarantee that the path is "/bin/sh": 107271 Applications should note that the standard PATH to the shell cannot be assumed to be either 107272 /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by 107273 getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell 107274 built-in. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s... POSIX mentions "#!" several times, but doesn't require it; saying things like "on systems that support executable scripts (the "#!" construct)". As the lack of a hard-codable path is frustrating, it recommends setting the shebang at install-time: 107279 Furthermore, on systems that support executable scripts (the "#!" construct), it is 107280 recommended that applications using executable scripts install them using getconf PATH to 107281 determine the shell pathname and update the "#!" script appropriately as it is being installed 107282 (for example, with sed). For example:

JdeBP 7y ago

As I wrote at https://unix.stackexchange.com/a/567405/5132 https://unix.stackexchange.com/a/567405/5132 , I have a strong suspicion that Arch Linux dropping the FHS is the tipping point, and adherence to the FHS is now the exception not the norm.

squiggleblaz 7y ago
Why would Arch dropping the FHS be the tipping point? Surely Arch represents hackers and not mainstream Linux users. In much the same way I wouldn't cite Linux users are a tipping point in any computer system convention (but Mac OS or Android or Windows), I wouldn't cite Arch in a Linux system convention (but Debian or Ubuntu or Red Hat). Why do you consider Arch as the tipping point?
- JdeBP 7y ago
  Because it would be, if my suspicion proves to be the case, the point where adherence to the FHS tips over from being the norm to the exception. MacOS, Windows, and who Arch users are have nothing to do with it. How many distribution creators have made each of the various choices, does. Arch's decision to use systemd had some influence (in both directions, c.f. Hyperbola Linux). Arch's decision to abandon the FHS in favour of the systemd file-hierarchy may well do likewise.