70

Anyone know this? I've never been able to find an answer.

Kenneth Reitz
  • 7,581
  • 4
  • 27
  • 34
  • 4
    not a ton. i'm on osx and the env manpage is rather ambiguous there. – Kenneth Reitz Aug 30 '09 at 02:37
  • 16
    @S.Lott: Have *you* read it lately? On my Debian box, it's one of the most unhelpful man pages I've ever seen, and that's saying something. (Here's the whole "Description": Set each NAME to VALUE in the environment and run COMMAND. Yup, that would clear him right up.) – Telemachus Aug 30 '09 at 02:42
  • @Telemachus: Yes, I did read it. It's why I found the Wikipedia entry. – S.Lott Aug 30 '09 at 02:44
  • 4
    One problem with env is that you can't add -u or any other option to be passed to the python executable – Arkady Aug 30 '09 at 02:56
  • interesting point. luckily, this isn't needed often for a shebang. – Kenneth Reitz Aug 30 '09 at 03:33
  • A very related (duplicate?) question: [Why do people write #!/usr/bin/env python on the first line of a Python script?](http://stackoverflow.com/questions/2429511/why-do-people-write-usr-bin-env-python-on-the-first-line-of-a-python-script) – Albert Nov 28 '12 at 00:39
  • 1
    Also a very good answer on a very related Unix SE question is [here](http://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my/29620#29620). – Albert Nov 28 '12 at 00:46

5 Answers5

67

If you're prone to installing python in various and interesting places on your PATH (as in $PATH in typical Unix shells, %PATH on typical Windows ones), using /usr/bin/env will accomodate your whim (well, in Unix-like environments at least) while going directly to /usr/bin/python won't. But losing control of what version of Python your scripts run under is no unalloyed bargain... if you look at my code you're more likely to see it start with, e.g., #!/usr/local/bin/python2.5 rather than with an open and accepting #!/usr/bin/env python -- assuming the script is important I like to ensure it's run with the specific version I have tested and developed it with, NOT a semi-random one;-).

Alex Martelli
  • 762,786
  • 156
  • 1,160
  • 1,345
  • 39
    Of course, you can always use #!/usr/bin/env python2.5 to constrain the set of semi-random choices :=) – Ned Deily Aug 30 '09 at 02:42
  • 1
    +1 Great explanation, thanks! I hadn't come across that usage of "env" before...now I have something to add to my scripting bag-of-tricks. – Jim Lewis Aug 30 '09 at 02:56
  • 3
    +1 for justification of NOT using "env python". Made me realize that if I want to use "env python", I'd better be coding for the lowest common denominator, since I'd have no control over the version of python the user has first in the PATH. – glenn jackman Aug 30 '09 at 18:47
  • 15
    -1 for several reasons: /usr/local/bin is not a standard path for python, would work only for *locally compiled installs*; Enforcing minor version at shebang a bad idea: may protect from 2.4, but it also claims your script is *incompatible with, say, 2.6 or 2.7*. Minor version restrain is a task for distutils/setup.py, package management system, or conditional imports, *not* shebang; Also, as @Ned said, you should not hardcode paths or prevent user for having his python 2.5 in ~/bin if the system does not provide one. **So, bad future-proof and abysmal portability.** – MestreLion Mar 23 '12 at 06:19
  • 3
    Be aware also of the fact that using `#!/usr/bin/env python` and virtualenvs will execute the script in current venv! This may or may not be a good thing, depends on your use case. – Pax0r Dec 01 '15 at 15:26
  • #!/usr/bin/env python3 would be a good compromise for those using python3, I reckon. i.e. it's specific enough but not too specific. My 2c. – Will Mar 28 '17 at 07:50
24

From wikipedia

Shebangs specify absolute paths to system executables; this can cause problems on systems which have non-standard file system layouts

Often, the program /usr/bin/env can be used to circumvent this limitation

user
  • 4,909
  • 7
  • 43
  • 60
S.Lott
  • 359,791
  • 75
  • 487
  • 757
10

it finds the python executable in your environment and uses that. it's more portable because python may not always be in /usr/bin/python. env is always located in /usr/bin.

Charles Ma
  • 41,485
  • 21
  • 80
  • 98
  • env is not always there, but we are increasing the probability of the script finding python on more machines. :) – Will Mar 28 '17 at 07:52
5

It finds 'python' also in /usr/local/bin, ~/bin, /opt/bin, ... or wherever it may hide.

Dirk Eddelbuettel
  • 331,520
  • 51
  • 596
  • 675
  • thanks! it actually caused a problem for me because, for some reason, env didn't' exist. – Kenneth Reitz Aug 30 '09 at 02:40
  • 3
    That's a bit misleading. It's only going to find the first "python" on your current $PATH and Python instances on OS X can be pretty good at hiding. In particular, the standard framework builds from python.org and others have "bin" subdirectories within the framework where "python" and other executables and scripts are stored. It's very easy to end up with multiple instances which may or may not have symlinks to them in the usual places, like /usr/local/bin et al. Managing $PATH on OS X in this case is not as straightforward as on systems without framework-style builds. – Ned Deily Aug 30 '09 at 02:51
  • 2
    @KennethReitz: if `/usr/bin/env` does not exist, your system is broken. `env`is a required tool by POSIX standard. – MestreLion Mar 23 '12 at 06:22
  • @MestreLion, POSIX is not a requirement for running python. – dadinck Jan 04 '13 at 22:55
  • @KennethReitz: true, but shebangs are used only in POSIX environments. Windows (and python) ignores them, so I assumed you were on *nix environment, otherwise your original question is moot. – MestreLion Jan 07 '13 at 01:47
3

You may find this post to be of interest: http://mail.python.org/pipermail/python-list/2008-May/661514.html

This may be a better explanation: http://mail.python.org/pipermail/tutor/2007-June/054816.html

James Black
  • 40,548
  • 9
  • 79
  • 153