News for hackers. Stuff that matters.

A comment on Understanding the bin, sbin, usr/bin, usr/sbin split (2010). Parent comment

Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by dwheeler on Wednesday March 18, 2020 @12:50PM (#22618650)
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/

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-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

[ Parent | on HN ]
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by LukeShu on Wednesday March 18, 2020 @02:56PM (#22620026)
(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/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:
[ Parent | on HN ]
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by JdeBP on Wednesday March 18, 2020 @03:56PM (#22620598)
As I wrote at 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.
[ Parent | on HN ]
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by squiggleblaz on Thursday March 19, 2020 @06:22AM (#22626134)
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?
[ Parent | on HN ]
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by JdeBP on Thursday March 19, 2020 @11:51AM (#22628608)
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.
[ Parent | on HN ]