zlacker

I put up an explanation of the difference between /bin, /usr/bin, /usr/local/bin, and ~/bin, as part of an argument why the "robustness" of using #!/usr/bin/env $binname vs. hardcoding #!/path/to/binname is not a good thing:

> The reason that depending on PATH is not considered good practice is that the script can make no assumptions about the content of the PATH environment variable, breaking the "sequential dependency model" of binaries where

1. /bin contains the executables needed at boot time;

2. /usr/bin contains the other executables used by the OS installation;

3. /usr/local/bin contains executables installed by the system administrator that are not part of the base OS.

4. ~/bin contains the user's own executables.

> Each level should not assume the existence of binaries later in the sequence, which are more "application" but may rely on binaries earlier, which are more "fundament". And the PATH variable tends to run from applicationy to fundamental, which is the opposite direction to the natural dependency above.

> To illustrate the problem, ask yourself what happens if a script in ~/bin invokes an script in /usr/local/bin that invokes Ruby? Should that script depend on the OS installed version at /usr/bin/ruby, or on the personal copy the user happens to have at ~/bin/ruby? PATH searching gives the unpredictable semantics associated with the latter (maybe ~/bin/ruby is a broken symbolic link), while baking in the path to #! gives the former.

On the Unix&Linux SX - http://unix.stackexchange.com/a/11917/5197

>>chalst+(OP)
Thanks! I've always thought /usr/bin was for software later installed (due to its name "user slash binaries") and thought /usr/local/bin was useless. This actually makes more sense, gonna start installing programs to /usr/local/bin now.

>>chalst+(OP)
I've historically been of opinion that #!/bin/name is preferred. Then I hit a workplace with network mappings and mixed architecture servers. It makes me appreciate linux's default mapping because when you start going off on your own it becomes nasty.

Some machines only have python 2.4 and others 2.7. So /usr/local/python is not a good answer for python scripts in /project/x/bin (network mapped). Worse someone puts gnu coreutils in /project/x/bin, but for sparc architectures, so PATH becomes touchy if you're on a x86 server.

I've resorted to having my bashrc build my path by scanning uname for architecture/platform and conditionally adding path entries to these network folders.

All organization scripts on network drives now have caveats "This only works on linux x86 servers" or "This only works on server X". Not because it can't work elsewhere, but because the PATH and #! management problems when the dependencies are installed at different places on different servers.

Blegh </rant>

>>chalst+(OP)
Or you run Arch, where every bin (including the sbins) is a symlink to /usr/bin, because in practice you just want your binaries in one place. Non-packaged binaries go in /usr/local/bin or something in opt.

>>chalst+(OP)
>#!/usr/bin/env $binname vs. hardcoding #!/path/to/binname

All of these "solutions" fail somewhere because some system does it differently. Why can't one just use #!bash or #!python and have the system just look on the path for it?

>>zanny+7l
Arch has recently merged all binaries to unified /usr/bin directory and got rid of /bin and /sbin.

https://www.archlinux.org/news/binaries-move-to-usrbin-requi...

>>grayli+si
You could create a script /usr/bin/dispatch that contains

    #!/bin/sh
    file=`env PATH=$THIS_ARCHITECURES_PREFERRED_PATH /usr/bin/which $1`
    shift; exit "$file" "$@"

for each machine to use in your scripts. Tuning the path becomes a once per architecture, rather than once per script, task.

>>klrr+ab
Here is what the Unix manual from Bell Labs (the origin of Unix) says about /usr/bin versus /bin:

    Commands generally reside in directory /bin
    (for binary programs). Some programs also 
     reside in /usr/bin, to save space in /bin.

There were hardware limitations in the early days of Unix. Short command names (like “ls” and “rm”) were used to save memory and paper (teletypes were used in the days before video terminals). Each byte mattered back then. There must have been a constraint on how much they could put in /bin (I am guessing).

Here is the manual:

http://plan9.bell-labs.com/7thEdMan/