Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I notice that some scripts which I have acquired from others have the shebang #!/path/to/NAME while others (using the same tool, NAME) have the shebang #!/usr/bin/env NAME.

Both seem to work properly. In tutorials (on Python, for example), there seems to be a suggestion that the latter shebang is better. But, I don't quite understand why this is so.

I realize that, in order to use the latter shebang, NAME must be in the PATH whereas the first shebang does not have this restriction.

Also, it appears (to me) that the first would be the better shebang, since it specifies precisely where NAME is located. So, in this case, if there are multiple versions of NAME (e.g., /usr/bin/NAME, /usr/local/bin/NAME), the first case specifies which to use.

My question is why is the first shebang preferred to the second one?

share|improve this question
See this answer... – jasonwryan Jan 21 '12 at 1:10
@TheGeeko61: In my case I had something broken and some variables wasn't in env. So I suggest to use this shebang to verify if env is correctly loaded. – Betterdev Jan 21 '12 at 10:52
up vote 189 down vote accepted

It isn't necessarily better.

The advantage of #!/usr/bin/env python is that it will use whatever python executable appears first in the user's $PATH.

The disadvantage of #!/usr/bin/env python is that it will use whatever python executable appears first in the user's $PATH.

That means that the script could behave differently depending on who runs it. For one user, it might use the /usr/bin/python that was installed with the OS. For another, it might use an experimental /home/phred/bin/python that doesn't quite work correctly.

And if python is only installed in /usr/local/bin, a user who doesn't have /usr/local/bin in $PATH won't even be able to run the script. (That's probably not too likely on modern systems, but it could easily happen for a more obscure interpreter.)

By specifying #!/usr/bin/python you specify exactly which interpreter will be used to run the script on a particular system.

Another potential problem is that the #!/usr/bin/env trick doesn't let you pass arguments to the intrepreter (other than the name of the script, which is passed implicitly). This usually isn't an issue, but it can be. Many Perl scripts are written with #!/usr/bin/perl -w, but use warnings; is the recommended replacement these days. Csh scripts should use #!/bin/csh -f -- but csh scripts are not recommended in the first place. But there could be other examples.

I have a number of Perl scripts in a personal source control system that I install when I set up an account on a new system. I use an installer script that modifies the #! line of each script as it installs it in my $HOME/bin. (I haven't had to use anything other than #!/usr/bin/perl lately; it goes back to times when Perl often wasn't installed by default.)

A minor point: the #!/usr/bin/env trick is arguably an abuse of the env command, which was originally intended (as the name implies) to invoke a command with an altered environment. Furthermore, some older systems (including SunOS 4, if I recall correctly) didn't have the env command in /usr/bin. Neither of these is likely to be a significant concern. env does work this way, a lot of scripts do use the #!/usr/bin/env trick, and OS providers aren't likely to do anything to break it. It might be an issue if you want your script to run on a really old system, but then you're likely to need to modify it anyway.

share|improve this answer
If /usr/bin/perl is perl 5.8, $HOME/bin/perl is 5.12, and a script requiring 5.12 hardcodes /usr/bin/perl in the shebangs, it can be a major pain to run the script. I've rarely seen having /usr/bin/env perl grab perl from the PATH be a problem, but it is often very helpful. And it is much prettier than the exec hack! – William Pursell Jan 25 '12 at 20:30
@WilliamPursell: You could always write a Perl script to replace the shebangs for you! – Keith Thompson Jan 26 '12 at 22:04
It's worth noting that, if you want to use a specific interpreter version, /usr/bin/env is still better. simply because there usually are multiple interpreter versions installed on your machine named perl5, perl5.12, perl5.10, python3.3, python3.32, etc. and if your app has only been tested on that specific version, you can still specify #!/usr/bin/env perl5.12 and be okay even if the user has it installed somewhere unusual. In my experience, 'python' is usually just a symlink to the system standard version (not necessarily the most recent version on the system). – root Jul 20 '13 at 19:44
@root: For Perl, use v5.12; serves some of that purpose. And #!/usr/bin/env perl5.12 will fail if the system has Perl 5.14 but not 5.12. For Python 2 vs. 3, #!/usr/bin/python2 and #!/usr/bin/python3 are likely to work. – Keith Thompson Jul 20 '13 at 21:44
If it doesn't work with /usr/bin/perl, I'll find out very quickly, and it's the system owner/administrator's responsibility to keep it up to date. If you want to run my script with your own perl, feel free to grab and modify a copy or invoke it via perl foo. (And you might consider the possibility that the 55 people who upvoted this answer also know a thing or two. It's certainly possible that you're right and they're all wrong, but that's not the way I'd bet.) – Keith Thompson Dec 14 '13 at 22:03

Because /usr/bin/env can interpret your $PATH, which makes scripts more portable.


Will only run your script if python is installed in /usr/local/bin.

#!/usr/bin/env python

Will interpret your $PATH, and find python in any directory in your $PATH.

So your script is more portable, and will work without modification on systems where python is installed as /usr/bin/python, or /usr/local/bin/python, or even custom directories (that have been added to $PATH), like /opt/local/bin/python.

Portability is the only reason using env is preferred to hard coded paths.

share|improve this answer
Custom directories for python executables are particularly common as virtualenv usage increases. – Xiong Chiamiov Nov 22 '13 at 0:01

Specifying the absolute path is more precise on a given system. The downside is that it's too precise. Suppose you realize that the system installation of Perl is too old for your scripts and you want to use your own instead: then you have to edit the scripts and change #!/usr/bin/perl to #!/home/myname/bin/perl. Worse, if you have Perl in /usr/bin on some machines, /usr/local/bin on others, and /home/myname/bin/perl on yet other machines, then you'd have to maintain three separate copies of the scripts and execute the appropriate one on each machine.

#!/usr/bin/env breaks if PATH is bad, but so does almost anything. Attempting to operate with a bad PATH is very rarely useful, and indicates that you know very little about the system the script is running on, so you can't rely on any absolute path anyway.

There are two programs whose location you can rely on on almost every unix variant: /bin/sh and /usr/bin/env. Some obscure and mostly retired Unix variants had /bin/env without having /usr/bin/env, but you're unlikely to encounter them. Modern systems have /usr/bin/env precisely because of its widespread use in shebangs. /usr/bin/env is something you can count on.

Apart from /bin/sh, the only time you should use an absolute path in a shebang is when your script isn't meant to be portable, so you can count on a known location for the interpreter. For example, a bash script that only works on Linux can safely use #!/bin/bash. A script that is only meant to be used in-house can rely on house interpreter location conventions.

#!/usr/bin/env does have downsides. It's more flexible than specifying an absolute path but still requires knowing the interpreter name. Occasionally you might want to run an interpreter that isn't in the $PATH, for example in a location relative to the script. In such cases, you can often make a polyglot script that can be interpreted both by the standard shell and by your desired interpreter. For example, to make a Python 2 script portable both to systems where python is Python 3 and python2 is Python 2, and to systems where python is Python 2 and python2 doesn't exist:

if type python2 >/dev/null 2>/dev/null; then
  exec python2 "$0" "$@"
  exec python "$0" "$@"
# real Python script starts here
def …
share|improve this answer

Specifically for perl, using #!/usr/bin/env is a bad idea for two reasons.

First, it's not portable. On some obscure platforms env isn't in /usr/bin. Second, as someone else has noted, it can cause trouble with passing arguments on the shebang line. The maximally portable solution is this:

exec perl -x $0 "$@"

For details on how it works, see 'perldoc perlrun' and what it says about the -x argument.

share|improve this answer
Exactly the anser I was looking for: how to write porable "shebang" for perl script that will allow additional aruments passed to perl (last line in your example accepts additional aruments). – AmokHuginnsson May 25 '15 at 21:23

The reason there is a distinction between the two is because of how scripts are executed.

Using /usr/bin/env (which, as mentioned in other answers, is not in /usr/bin on some OSes) is required because you can't just put an executable name after the #! - it must be an absolute path. This is because the #! mechanism works on a lower level than the shell. It's part of the kernel's binary loader. This can be tested. Put this in a file and mark it executable:


echo 'foo'

You will find it prints an error like this when you attempt to run it:

Failed to execute process './test.sh'. Reason:
The file './test.sh' does not exist or could not be executed.

If a file is marked executable and begins with a #!, the kernel (which does not know about $PATH or the current directory: these are user-land concepts) will look for a file using an absolute path. Because using an absolute path is problematic (as mentioned in other answers), someone came up with a trick: You can run /usr/bin/env (which is almost always in that location) to run something using $PATH.

share|improve this answer

Adding another example here:

Using env is also useful when you want to share scripts between multiple rvm environments for example.

Running this on the cmd line, shows which ruby version will be used when #!/usr/bin/env ruby is used inside a script:

env ruby --version

Therefore, when you use env, you can use different ruby versions through rvm, without changing your scripts.

share|improve this answer
// , Excellent idea. The whole point of multiple interpreters is NOT to break the code, or to have code depend upon that specific interpreter. – Nathan Basanese Jan 15 at 20:52

If you're writing purely for yourself or for your job and the location of the interpreter you're calling is always in the same place, by all means use the direct path. In all other cases use #!/usr/bin/env.

Here's why: in your situation the python interpreter was in same place regardless of which syntax you used but for many people it could have installed in a different place. Though most major programming interpreters are located in /usr/bin/ a lot of newer software is defaulting to /usr/local/bin/.

I would even argue to always use #!/usr/bin/env because if you have multiple versions of the same interpreter installed and you don't know what your shell will default to, then you should probably fix that.

share|improve this answer

There are two more problems with using #!/usr/bin/env

  1. It doesn't solve the problem of specifying the full path to the interpreter, it just moves it to env. env is no more guaranteed to be in /usr/bin/env than bash is guaranteed to be in /bin/bash or python in /usr/bin/python.

  2. env overwrites ARGV[0] with the name of the interpreter (e..g bash or python). This prevents your script's name from appearing in, e.g., ps output and makes it impossible to find it with pgrep myscript.py or ps -C scriptname.sh

share|improve this answer
Both of these potential issues have already been mentioned in existing answers. In any case, env is much more likely to be in /usr/bin/env than bash or python being in any specific location. – jlliagre Oct 25 '15 at 7:23
Nobody else here has mentioned the ARGV[0] problem. And nobody has mentioned the /path/to/env issue in a form that directly addresses one of the arguments for using it (i.e. that bash or perl might be in an unexpected location). – cas Oct 25 '15 at 7:55
Sorry, you are right about the argv[0] issue, I was confusing with another thread. Your first point is still questionable. Using env in the first place assumes the command to launch is in the user's PATH and is a portable way to publish a script giving it the best opportunity to be executable whatever the target system. If that target command (e.g python, perl) is not in the PATH, there is no portable way to specify it in the script shebang anyway. – jlliagre Oct 25 '15 at 8:16
The interpreter path issue is easily fixed by a sysadmin with symlinks, or by the user editing their script. It's certainly not a significant enough problem to encourage people to put up with the all of the other issues caused by using env on the shebang line that are mentioned here and on other questions. That's promoting a bad solution in the same kind of way that encouraging csh scripting is promoting a bad solution: it kind of works but there are much better alternatives. – cas Oct 25 '15 at 8:37
non-sysadmins can ask their sysadmin to do it. or they can simply edit the script and change the #! line. – cas Oct 25 '15 at 10:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.