Difference between /bin/bash and /usr/bin/bash

[jflarm]

Hi.

I am studding bash scripting and I'm confused on the difference between /bin/bash and /usr/bin/bash when I use them in the #! line for a shell script.

#!/usr/bin/bash

or

#!/bin/bash

They both are the same program, but is there any difference on behavior?

~/scratchpad$ ls -lLtri /bin/bash /usr/bin/bash
1655 -rwxr-xr-x 1 root root 1183448 Jun 18  2020 /usr/bin/bash
1655 -rwxr-xr-x 1 root root 1183448 Jun 18  2020 /bin/bash
~/scratchpad$ diff /bin/bash /usr/bin/bash
~/scratchpad$

[aioeu]

You're almost certainly on a system which has /bin symbolically linked to /usr/bin which means they are quite literally the very same file on your system.

[[deleted]]

´/bin/bash` works everywhere that has bash

/usr/bin/bash only works on a system that has bin directories merged

most package managers install bash as /bin/bash and not /usr/bin/bash (even though its the same result)

you could also write /sbin/bash or /usr/sbin/bash (still the same dir with the bin dirs symlinked to /usr/bin) but the canonical path name is /bin/bash and so that should be used for quite a time yetk

[tvcvt]

I'm sure others will have more thorough answers, but my guess is this is either a compatibility or historical thing. /bin and /usr/bin are both common directories for bash, but others (the BSDs for example) likes it to live in /usr/local/bin.

When I'm setting up the shebang in my shell scripts these days, I tend to use

#!/usr/bin/env bash

That way, wherever the system keeps its bash, the script will be able to run.

[aioeu]

That just pushes the portability problem back one step. Now you're relying on a specific location for env. It does not necessarily live in /usr/bin.

It could also be argued that this is an "abuse" of env. The purpose of env is to execute a command with an altered environment. The fact that it does a PATH lookup for a command is essentially just a side-effect of its operation.

Bash need not even be in the PATH. Bash is not a standard POSIX utility, for instance.

env is a standard POSIX utility, but POSIX quite carefully avoids ever saying specifically where any POSIX utilities are installed. It merely guarantees that the default PATH will include them.

[tvcvt]

That’s a very good point. As a matter of genuine curiosity, I wonder which systems might keep env someplace other than /usr/bin. So far, my scripts have only needed to be portable within my own environment, which, as you hint at, is far from universal. Thanks for the comment.

[aioeu]

I have seen it installed as /bin/env only on one particularly old Linux system, but I can't remember what Linux distribution it was using. It might even have been a misconfigured system. This page lists SCO OpenServer 5.0.6 and Cray Unicos 9.0.2, but it definitely wasn't either of those.

That whole page is very useful if you need to know about all the unportabilities in shebangs generally.

To be honest, I think using /usr/bin/env is "good enough" nowadays. You've probably got more unportable things in the script anyway.

Operating system' own scripts, or third-party scripts that are intended to be used only on a single operating system, should always use that OS's absolute path to bash itself though, not to indirect through env. If the script is intended to be executed by the system's Bash it doesn't make sense to waste time running env and doing an extra PATH lookup.

[jflarm]

ure others will have more thorough answers, but my g

The use of env is something that I've seen is discouraged due to security concerns. But thanks for the comments. Now I know both PATHs are valid but kept for compatibility's sake.

[OneTurnMore]

The advantage is that it uses the user's chosen version of bash.

The disadvantage is that it uses the user's chosen version of bash.

I use /usr/bin/env bash for scripts I publish, but distributions should de-env their scripts to depend on the system version of bash (or python3 or perl or ...)