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