#!/usr/bin/env python vs. #!/usr/bin/python

Discussion in 'Python' started by Yves Dorfsman, May 2, 2008.

  1. On UNIX, some people use
    #!/usr/bin/env python

    While other use
    #!/usr/bin/python

    Why is one preferred over the other one ?

    Thanks.

    --
    Yves.
    http://www.SollerS.ca
    Yves Dorfsman, May 2, 2008
    #1
    1. Advertising

  2. Yves Dorfsman

    Roy Smith Guest

    In article <>,
    Ben Finney <> wrote:

    > I've never clearly understood why people want to use "#! /usr/bin/env
    > python", which is prone to finding a different Python from the one
    > installed by the operating system. I'd be interested to see what
    > responses are in favour of it, and what the reasoning is.
    >
    > One possible reason is that the programmer is attempting to allow for
    > systems where Python has been installed, but not from an operating
    > system package.


    You've got it exactly.

    I'm currently using Python to write unit tests as part of a build system.
    Many of our development boxes don't have python installed in /usr/bin (or
    perhaps at all). And even if they did, we might want to use a different
    version of Python on different branches of the code.

    We've got Python built for all our platforms and the binaries stored in our
    source control system. When you check out a particular branch, you get the
    right version of Python for that branch. By having the Python scripts
    start with #!/usr/bin/env python, I can select the version of Python I want
    just by changing the environment.

    Then, of course, I recently ran across a machine where env was installed in
    /opt/gnu/bin instead of /usr/bin. Sigh. Sometimes you just can't win.
    Roy Smith, May 2, 2008
    #2
    1. Advertising

  3. On Fri, 02 May 2008 13:24:01 +1000
    Ben Finney <> wrote:
    > I much prefer "#! /usr/bin/python" because I want my Python programs
    > to, by default, be run with the default Python, and depend on Python
    > being installed by the operating system's package manager. On systems
    > that use shebang lines and that actually have standardised filesystem
    > locations, the default Python is found at '/usr/bin/python'.


    You have lived a sheltered life. Not every packaging system puts the
    executible in /usr/bin. Many systems use /usr/local/bin. NetBSD
    uses /usr/pkg/bin but allows you to define your own pkg root.
    Using /usr/bin/env allows your code to run on all these systems.

    --
    D'Arcy J.M. Cain <> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
    D'Arcy J.M. Cain, May 2, 2008
    #3
  4. -On [20080502 05:26], Ben Finney () wrote:
    >I've never clearly understood why people want to use "#! /usr/bin/env
    >python", which is prone to finding a different Python from the one
    >installed by the operating system. I'd be interested to see what
    >responses are in favour of it, and what the reasoning is.


    Simple, some systems are not as peculiar as a lot of Linux boxes which
    chug everything into /usr/bin, which is OS territory (as has been decreed
    long ago by hier(7)), but rather use /usr/local/bin (all BSD Unix and
    derivatives) or /opt or whatever convention a particular operating system
    has.

    And prone to find the wrong Python, it all depends upon proper $PATH
    administration.

    As such, your script with #!/usr/bin/python is as bad as an ash shell script
    with #!/bin/bash. #!/usr/bin/env python is more cross-OS friendly, there's
    more than just Linux you know.

    --
    Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
    イェルーン ラウフロック ヴァン デル ウェルヴェン
    http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
    I dream of Love as Time runs through my hand...
    Jeroen Ruigrok van der Werven, May 2, 2008
    #4
  5. Yves Dorfsman

    Tim Roberts Guest

    Yves Dorfsman <> wrote:
    >
    >On UNIX, some people use
    >#!/usr/bin/env python
    >
    >While other use
    >#!/usr/bin/python
    >
    >Why is one preferred over the other one ?


    The /usr/bin/env solution finds the Python interpreter anywhere on the
    PATH, whether it be /usr/bin or /usr/local/bin, or whatever. With
    /usr/bin/python, it MUST be in /usr/bin.

    Way back when, Python wasn't included in Linux distributions by default, so
    it was difficult to predict where it would be. /usr/bin/env, on the other
    hand, is well-established at that location.

    These days, since Python is nearly ubiquitous, I suspect it is not so
    important.
    --
    Tim Roberts,
    Providenza & Boekelheide, Inc.
    Tim Roberts, May 2, 2008
    #5
  6. -On [20080502 07:51], Ben Finney () wrote:
    >To my mind, the Python interpreter installed by a package as
    >distributed with the OS *is* OS territory and belongs in /usr/bin/.


    That's the difference with a distribution, such as Linux, and full OSes ,
    such as BSDs or commercial Unix variants. They prefer to keep a pristine
    state for the OS vendor files versus what the user can opt to install
    himself, hence the /usr/bin - /usr/local/bin separation. Same for sbin, lib,
    and so on. It effectively guarantees you can nuke /usr/local without ill
    consequences for your OS.

    Different philosophies, but after having spent more than 10+ years on too
    many Unix and Unix-like systems I know the importance of platform
    portability a bit too much and hardcoding a shebang sequence is not the
    solution in general. Using env is the, arguably, best solution available.

    --
    Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
    イェルーン ラウフロック ヴァン デル ウェルヴェン
    http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
    Felix, qui potuit rerum cognoscere causas...
    Jeroen Ruigrok van der Werven, May 2, 2008
    #6
  7. On Fri, 02 May 2008 15:50:22 +1000
    Ben Finney <> wrote:
    > > You have lived a sheltered life. Not every packaging system puts the
    > > executible in /usr/bin. Many systems use /usr/local/bin.

    >
    > They use that for the operating-system-installed default Python
    > interpreter? Colour me incredulous.


    OK, let me get out my crayons. However, note that I did not say
    "operating-system-installed." I said a packaging system puts it
    there. In fact, the NetBSD packaging system works on many systems
    including Linux and thus is not an operating system packager.

    --
    D'Arcy J.M. Cain <> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
    D'Arcy J.M. Cain, May 2, 2008
    #7
  8. * Ben Finney (Fri, 02 May 2008 23:30:01 +1000)
    > The OP was asking why people prefer on over the other. My answer is
    > that I prefer specifying "give me the default OS Python" because
    > anything not installed by the OS is to non-standardised for me to
    > worry about.
    >
    > Others may prefer something different, but then they get to wear
    > whatever problems occur as a result of that choice. I continue to be
    > bemused by that preference, and nothing that I've seen so far in this
    > thread illuminates the issue more.


    You're missing the point. Apart from the really dubious terms you use
    ("OS installable package"), using env in the first line has exactly the
    effect to use the default path of Python (which is the first entry in
    your path) and not some hard-coded path (which might not even exist).

    Thorsten
    Thorsten Kampe, May 2, 2008
    #8
  9. Yves Dorfsman

    Roy Smith Guest

    In article <>,
    Ben Finney <> wrote:

    > Whereas if Python is *not* installed from an OS package, it's up to
    > the sys admin to ensure that it works -- not up to my program. So I
    > don't see the point in making it work by default, when what I want for
    > my program is that it works *with the default Python*, not with some
    > non-default installation.


    Ben,

    Have you ever shipped software to a customer? Imagine the following
    conversation:

    Customer: "Your product is broken. It says it can't find python, and I
    know I have it installed".

    Vendor: "Where do you have it installed?"

    Customer: "In /opt/bin/python"

    Vendor: "Oh, that's your problem, it HAS to be in /usr/bin/python".

    Customer: "I can't install it there because <insert whatever silly reason
    the customer has>. If you can't make your product work without requiring
    me to install python in /usr/bin, I'm afraid I can't buy your product".

    Vendor: "No problem sir, I'll be happy to tell our sales folks to stop
    bothering you".

    If you want to hard-code /usr/bin/python into your application, that's your
    decision. If you would like to take on the task of convincing every
    sysadmin in the world to do things the way you think they should be done,
    have fun.
    Roy Smith, May 2, 2008
    #9
  10. On Fri, 02 May 2008 23:30:01 +1000
    Ben Finney <> wrote:
    > The OP was asking why people prefer on over the other. My answer is
    > that I prefer specifying "give me the default OS Python" because
    > anything not installed by the OS is to non-standardised for me to
    > worry about.


    As someone else pointed out, not all the world is Linux. So your
    version of Linux (I'm not sure whether it is true for all versions or
    not) delivers Python as part of the OS. That is simply not true of the
    whole world. Some OS distributions have an adjunct facility for
    installing packages but they are not part of the OS. Some systems
    don't even have that and people must download packages such as Python
    and install them manually. Even on Linux there are people who won't
    install binaries and use NetBSD's pkgsrc instead. Clearly that cannot
    install into /usr/bin since it is not part of the OS.

    Certainly #! /usr/bin/python is fine if you never expect your software
    to run outside of your own little corner of the world but you asked why
    people prefer the env version and the answer is that we want to write
    software that runs everywhere that Python runs.

    --
    D'Arcy J.M. Cain <> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
    D'Arcy J.M. Cain, May 2, 2008
    #10
  11. Re: #!/usr/bin/env python vs. #!/usr/bin/python

    On Fri, 02 May 2008 16:26:51 +0200
    Torsten Bronger <-aachen.de> wrote:
    > > Certainly #! /usr/bin/python is fine if you never expect your
    > > software to run outside of your own little corner of the world but
    > > you asked why people prefer the env version and the answer is that
    > > we want to write software that runs everywhere that Python runs.

    >
    > Granted, but you must draw the line somewhere anyway. I cannot


    No one is talking about if statements here.

    --
    D'Arcy J.M. Cain <> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
    D'Arcy J.M. Cain, May 2, 2008
    #11
  12. On Sat, 03 May 2008 00:44:00 +1000
    Ben Finney <> wrote:
    > "D'Arcy J.M. Cain" <> writes:
    > > As someone else pointed out, not all the world is Linux.

    >
    > It's a good thing I've never implied such to be the case.


    You haven't *said* it but you have definitely *implied* it. Installing
    Python in /usr/bin is not common. It is very specific to your system.

    --
    D'Arcy J.M. Cain <> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
    D'Arcy J.M. Cain, May 2, 2008
    #12
  13. On Sat, 03 May 2008 00:43:02 +1000
    Ben Finney <> wrote:
    > Roy Smith <> writes:
    > > Have you ever shipped software to a customer?

    >
    > Yes, and all parties have been quite happy with the results.


    When some of us talk about shipping software we aren't talking about a
    20 line script delivered to our uncle's construction company office. We
    are talking about millions of lines of code in thousands of programs and
    modules that has to run out of the box on whatever system the client
    happens to run on.

    > > Customer: "I can't install it there because <insert whatever silly
    > > reason the customer has>. If you can't make your product work
    > > without requiring me to install python in /usr/bin, I'm afraid I
    > > can't buy your product".

    >
    > At this point they have the simple option of running the program with
    > 'python /path/to/the/program'. It's certainly not a case of "can't
    > make the product work".


    Simple for your 20 line single script. Not so simple for my million
    line, integrated system that has to work everywhere.

    > It is, however, a case of "can't automatically account for every local
    > customisation sysadmins choose to make on their systems". Perfectly
    > willing to work with them to get their specific environment working,
    > but as a matter of simple economics it's not worth my time to attempt
    > to make such corner cases work automatically.


    If by "corner case" you mean "some system that I don't personally run"
    then OK but to some of us your system is the corner case and we would
    like our code to run there as well.

    Real software has to deal with the fact that support costs money.
    You may be able to deal with one or two clients that way but that does
    not scale very well.

    > If they've already chosen to install Python to some unpredictable
    > location, they know what they're doing enough to invoke the program in
    > a specific way to get it working.


    Unpredictable to you. Perfectly predictable on their system.

    I do believe I am done with this thread.

    --
    D'Arcy J.M. Cain <> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
    D'Arcy J.M. Cain, May 2, 2008
    #13
  14. Thanks everybody, I didn't mean to start a flamewar...
    I do get it now, it's whatever python is in the path, vs. the specific one
    you're pointing to.

    Ben Finney wrote:

    >
    > No, because it's quite common for the PATH variable to have
    > '/usr/local/bin' appear *before* both of '/bin' and '/usr/bin'.
    >
    > If the system has a sysadmin-installed '/usr/local/bin/python'
    > installed as well as the OS-installed '/usr/bin/python', then the two
    > shebang options the OP raised will behave differently on such a
    > system. This seems to be quite the point of the discussion.
    >


    And I have to admit, I prefer specifying the version (full path) because I
    have run into too many problem when users have different PATHs and end up
    running different version of an interpreter.

    Yves.
    --
    http://www.SollerS.ca
    Yves Dorfsman, May 2, 2008
    #14
  15. * Ben Finney (Sat, 03 May 2008 00:37:45 +1000)
    > Thorsten Kampe <> writes:
    > > * Ben Finney (Fri, 02 May 2008 23:30:01 +1000)
    > > > The OP was asking why people prefer on over the other. My answer
    > > > is that I prefer specifying "give me the default OS Python"
    > > > because anything not installed by the OS is to non-standardised
    > > > for me to worry about.
    > > >
    > > > Others may prefer something different, but then they get to wear
    > > > whatever problems occur as a result of that choice. I continue to
    > > > be bemused by that preference, and nothing that I've seen so far
    > > > in this thread illuminates the issue more.

    > >
    > > You're missing the point. Apart from the really dubious terms you
    > > use ("OS installable package"), using env in the first line has
    > > exactly the effect to use the default path of Python (which is the
    > > first entry in your path)

    >
    > No, because it's quite common for the PATH variable to have
    > '/usr/local/bin' appear *before* both of '/bin' and '/usr/bin'.
    >
    > If the system has a sysadmin-installed '/usr/local/bin/python'
    > installed as well as the OS-installed '/usr/bin/python', then the two
    > shebang options the OP raised will behave differently on such a
    > system. This seems to be quite the point of the discussion.


    Again you're missing the point. If you or whoever installs Python (or
    another version of Python) to /usr/local/bin and puts this in the path
    to front (as it's often done) then /you/ want that Python to be the
    "default" one. It would just be silly to say "no, I the developer want
    /usr/bin/python".

    So in general "#! env" is better while in certain circumstance
    hardcoding the path to /usr/bin/python can be better.


    Thorsten
    Thorsten Kampe, May 2, 2008
    #15
  16. Yves Dorfsman

    Carl Banks Guest

    Re: #!/usr/bin/env python vs. #!/usr/bin/python

    On May 2, 11:07 am, "D'Arcy J.M. Cain" <> wrote:
    > On Sat, 03 May 2008 00:43:02 +1000
    >
    > Ben Finney <> wrote:
    > > Roy Smith <> writes:
    > > > Have you ever shipped software to a customer?

    >
    > > Yes, and all parties have been quite happy with the results.

    >
    > When some of us talk about shipping software we aren't talking about a
    > 20 line script delivered to our uncle's construction company office. We
    > are talking about millions of lines of code in thousands of programs and
    > modules that has to run out of the box on whatever system the client
    > happens to run on.


    If you're shipping a program that large you out to be packaging the
    Python interpreter with it.

    Frankly, this whole discussion is silly, as if it's some kind hard
    thing to open the script with a text editor and modify the shbang
    line.


    Carl Banks



    > > > Customer: "I can't install it there because <insert whatever silly
    > > > reason the customer has>. If you can't make your product work
    > > > without requiring me to install python in /usr/bin, I'm afraid I
    > > > can't buy your product".

    >
    > > At this point they have the simple option of running the program with
    > > 'python /path/to/the/program'. It's certainly not a case of "can't
    > > make the product work".

    >
    > Simple for your 20 line single script. Not so simple for my million
    > line, integrated system that has to work everywhere.
    >
    > > It is, however, a case of "can't automatically account for every local
    > > customisation sysadmins choose to make on their systems". Perfectly
    > > willing to work with them to get their specific environment working,
    > > but as a matter of simple economics it's not worth my time to attempt
    > > to make such corner cases work automatically.

    >
    > If by "corner case" you mean "some system that I don't personally run"
    > then OK but to some of us your system is the corner case and we would
    > like our code to run there as well.
    >
    > Real software has to deal with the fact that support costs money.
    > You may be able to deal with one or two clients that way but that does
    > not scale very well.
    >
    > > If they've already chosen to install Python to some unpredictable
    > > location, they know what they're doing enough to invoke the program in
    > > a specific way to get it working.

    >
    > Unpredictable to you. Perfectly predictable on their system.
    >
    > I do believe I am done with this thread.
    >
    > --
    > D'Arcy J.M. Cain <> | Democracy is three wolveshttp://www.druid.net/darcy/ | and a sheep voting on
    > +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
    Carl Banks, May 2, 2008
    #16
  17. Yves Dorfsman

    Robert Kern Guest

    Yves Dorfsman wrote:
    > On UNIX, some people use
    > #!/usr/bin/env python
    >
    > While other use
    > #!/usr/bin/python
    >
    > Why is one preferred over the other one ?


    Caveat: I've only read *most* of this thread, so maybe someone else has already
    made the following point.

    It depends on the context. Ultimately, when your script is installed, it (almost
    certainly) should point to the precise Python executable the installer intends
    it to run on. One of the features of distutils is that it will *rewrite*
    "#!/usr/bin/env python" to use the exact executable that the installer used to
    execute the setup.py.

    So *as a developer* I recommend writing your scripts with "#!/usr/bin/env
    python". This lets distutils select the correct executable, and it lets your
    users play around with your scripts prior to installation without needing to
    rewrite the shebang line manually. I hate trying out someone's code just to find
    that that they hardcoded /usr/local/bin/python2.3. If you aren't using distutils
    to install for some reason, you might want to recommend that the installer
    change the shebang line in your installation instructions.

    --
    Robert Kern

    "I have come to believe that the whole world is an enigma, a harmless enigma
    that is made terrible by our own mad attempt to interpret it as though it had
    an underlying truth."
    -- Umberto Eco
    Robert Kern, May 2, 2008
    #17
  18. En Fri, 02 May 2008 12:07:55 -0300, D'Arcy J.M. Cain <>
    escribió:
    > On Sat, 03 May 2008 00:43:02 +1000
    > Ben Finney <> wrote:
    >> Roy Smith <> writes:


    >> > Have you ever shipped software to a customer?

    >>
    >> Yes, and all parties have been quite happy with the results.

    >
    > When some of us talk about shipping software we aren't talking about a
    > 20 line script delivered to our uncle's construction company office. We
    > are talking about millions of lines of code in thousands of programs and
    > modules that has to run out of the box on whatever system the client
    > happens to run on.
    > [...]
    > Simple for your 20 line single script. Not so simple for my million
    > line, integrated system that has to work everywhere.


    In that case you have a setup script, I presume. You use distutils or a
    better alternative, I presume. You use the scripts= argument to setup, or
    the install_scripts distutils command, I presume. The first line on your
    scripts starts with #! and contains the word python somewhere, I presume.
    Then, distutils will adjust that shebang line using the same python
    executable that was used to run the installation.
    It doesn't matter whether the line read #!/usr/bin/python, #!/usr/bin/env
    python, #~/bin/python2.3 or just #!python: whatever Python was used to
    install your program, that will be written as the first line on the
    script, and consequentely that will be used to execute the script in the
    future. So the admin (or whoever installs the system) only has to make
    sure to use the right Python version from the right directory. That's all.
    Plain easy, isn't it?

    I can't believe some angry responses in this thread - it's just a
    technical question, not about which is the best team in the [preferred
    sports here] National Championship...

    --
    Gabriel Genellina
    Gabriel Genellina, May 3, 2008
    #18
  19. Yves Dorfsman

    Lou Pecora Guest

    In article <A72dnRnGiotPr4bVnZ2dnUVZ_qTinZ2d@visi>,
    Grant Edwards <> wrote:

    > On 2008-05-02, D'Arcy J.M. Cain <> wrote:
    > > On Sat, 03 May 2008 00:44:00 +1000
    > > Ben Finney <> wrote:
    > >> "D'Arcy J.M. Cain" <> writes:
    > >> > As someone else pointed out, not all the world is Linux.
    > >>
    > >> It's a good thing I've never implied such to be the case.

    > >
    > > You haven't *said* it but you have definitely *implied* it.
    > > Installing Python in /usr/bin is not common.

    >
    > It is common. That's where it's installed by almost all Linux
    > distributions.


    MacOS X system python (or links to them) is in the same place.

    --
    -- Lou Pecora
    Lou Pecora, May 3, 2008
    #19
  20. Yves Dorfsman

    Aahz Guest

    Aahz, May 3, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Parzival
    Replies:
    4
    Views:
    57,556
    Erik Max Francis
    Nov 10, 2003
  2. Adriano Ferreira
    Replies:
    9
    Views:
    570
    Mike Meyer
    Dec 3, 2005
  3. John Salerno
    Replies:
    30
    Views:
    1,941
    Stephan Kuhagen
    Aug 10, 2006
  4. anne001
    Replies:
    1
    Views:
    401
  5. Gilles
    Replies:
    7
    Views:
    544
    Matej Cepl
    Sep 30, 2012
Loading...

Share This Page