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:<p>> 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<p>1. /bin contains the executables needed at boot time;<p>2. /usr/bin contains the other executables used by the OS installation;<p>3. /usr/local/bin contains executables installed by the system administrator that are not part of the base OS.<p>4. ~/bin contains the user's own executables.<p>> 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.<p>> 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.<p>On the Unix&Linux SX - <a href="http://unix.stackexchange.com/a/11917/5197" rel="nofollow">http://unix.stackexchange.com/a/11917/5197</a>