#!/usr/bin/python or #!/usr/bin/env python?

Discussion in 'Python' started by John Salerno, Aug 8, 2006.

  1. John Salerno

    John Salerno Guest

    I understand the difference, but I'm just curious if anyone has any
    strong feelings toward using one over the other? I was reading that a
    disadvantage to the more general usage (i.e. env) is that it finds the
    first python on the path, and that might not be the proper one to use. I
    don't know if that's a real issue most of the time, but it's at least
    something to consider.

    And is Python found in directories other than /usr/bin often enough to
    justify using the more general form?
     
    John Salerno, Aug 8, 2006
    #1
    1. Advertising

  2. John Salerno wrote:
    > I understand the difference, but I'm just curious if anyone has any
    > strong feelings toward using one over the other? I was reading that a
    > disadvantage to the more general usage (i.e. env) is that it finds the
    > first python on the path, and that might not be the proper one to use.


    I don't see how that's any different from when the Python at
    /usr/bin/python isn't the right one to use. I know that's true at my
    university:

    $ /usr/bin/python -V
    Python 2.2.3
    $ /usr/local/python/bin/python -V
    Python 2.4.3

    With this setup, the one in /usr/bin is for the OS and is seldom
    updated, and the one in /usr/local is for users and is updated frequently.

    Sure, if someone doesn't put /usr/local/python/bin on their PATH,
    they're not going to get the right Python, but I don't write code to
    Python 2.2 anymore, so if I use ``#!/usr/bin/python`` my code will
    probably just fail.

    Obviously, in my own code, I only use ``#!/usr/bin/env python``.

    STeVe
     
    Steven Bethard, Aug 8, 2006
    #2
    1. Advertising

  3. John Salerno schrieb:
    > I understand the difference, but I'm just curious if anyone has any
    > strong feelings toward using one over the other?


    I use /usr/bin/env if I don't know what the operating system is;
    some systems don't have Python in /usr/bin. I use /usr/bin/pythonX.Y
    if I want a specific version on a specific operating system (typically
    Linux). I use /usr/bin/python when I'm too lazy to think about it
    thoroughly.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 8, 2006
    #3
  4. John Salerno

    Guest

    John> I understand the difference, but I'm just curious if anyone has
    John> any strong feelings toward using one over the other?

    #!/usr/bin/python -> never

    #!/usr/bin/env python -> always

    Strong enough?


    John> I was reading that a disadvantage to the more general usage
    John> (i.e. env) is that it finds the first python on the path

    That's generally the one you want. On most systems /usr/bin/python will be
    the system-provided one (e.g. the one that came with your Linux
    distribution). You might prefer a Python of more recent vintage though.
    That's commonly installed in /usr/local/bin/python and /usr/local/bin is
    generally ahead of /usr/bin in PATH.

    John> And is Python found in directories other than /usr/bin often
    John> enough to justify using the more general form?

    On my Mac I install most stuff in ~/local simply so I don't need to be
    root and don't disturb the system-provided software. In cases where other
    users need to run such tools I generally use /usr/local.

    Skip
     
    , Aug 8, 2006
    #4
  5. John Salerno

    John Salerno Guest

    wrote:

    > On most systems /usr/bin/python will be
    > the system-provided one (e.g. the one that came with your Linux
    > distribution). You might prefer a Python of more recent vintage though.
    > That's commonly installed in /usr/local/bin/python and /usr/local/bin is
    > generally ahead of /usr/bin in PATH.


    Ah, that answered my next question too! I guess I'll stick with the env
    method, since I like the more general, abstract stuff over the absolute
    anyway.
     
    John Salerno, Aug 8, 2006
    #5
  6. John Salerno wrote:

    > I understand the difference, but I'm just curious if anyone has any
    > strong feelings toward using one over the other? I was reading that a
    > disadvantage to the more general usage (i.e. env) is that it finds the
    > first python on the path, and that might not be the proper one to use. I
    > don't know if that's a real issue most of the time, but it's at least
    > something to consider.
    >
    > And is Python found in directories other than /usr/bin often enough to
    > justify using the more general form?


    Yes. If Python (or indeed any other well-behaving software) is
    installed manually, it will _not_ be installed in /usr/bin. /usr is
    where your primary OS/distribution installation goes. Additional
    software goes elsewhere, such as /usr/local.

    Always prefer to use env over a hardcoded path, because that hardcoded
    path will invariably be wrong. (Yes, for those about to nitpick, it's
    conceivable that env might be somewhere other than /usr/bin. However,
    that is very rare and results in a no-win situations regardless of the
    issue of where Python is installed.)

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
    Never contend with a man who has nothing to lose.
    -- Baltasar Gracian, 1647
     
    Erik Max Francis, Aug 8, 2006
    #6
  7. Martin v. Löwis wrote:

    > I use /usr/bin/env if I don't know what the operating system is;
    > some systems don't have Python in /usr/bin. I use /usr/bin/pythonX.Y
    > if I want a specific version on a specific operating system (typically
    > Linux).


    Even there, /usr/bin/env pythonX.Y would be a better choice. (Maybe
    that's what you meant.)

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
    Never contend with a man who has nothing to lose.
    -- Baltasar Gracian, 1647
     
    Erik Max Francis, Aug 8, 2006
    #7
  8. Erik Max Francis schrieb:
    >> I use /usr/bin/env if I don't know what the operating system is;
    >> some systems don't have Python in /usr/bin. I use /usr/bin/pythonX.Y
    >> if I want a specific version on a specific operating system (typically
    >> Linux).

    >
    > Even there, /usr/bin/env pythonX.Y would be a better choice. (Maybe
    > that's what you meant.)


    I'm uncertain. When I refer to /usr/bin/python2.3, I know I get the
    system vendor's installation. When I use /usr/bin/env python2.3, I
    may get something that somebody has build and which may not work
    at all, or lack certain add-on packages that the script needs.
    It's bad when the script works for some users but fails for others.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 8, 2006
    #8
  9. > Always prefer to use env over a hardcoded path, because that hardcoded
    > path will invariably be wrong. (Yes, for those about to nitpick, it's
    > conceivable that env might be somewhere other than /usr/bin. However,
    > that is very rare and results in a no-win situations regardless of the
    > issue of where Python is installed.)


    Don't yell at me for bringing in another language, but I really like the
    trick, Tcl does:

    > #!/bin/sh
    > # The next line starts Tcl \
    > exec tclsh "$0" "$@"


    This works by the somewhat weird feature of Tcl, that allows comments to be
    continued in the next line with "\" at the end of the comment-line. It
    looks unfamiliar, but has several advantages, I think. First it's really
    VERY unlikely, that there is no /bin/sh (while I found systems with
    different places for env), and you can add some other features at or before
    the actual call of the interpreter, i.e. finding the right or preferred
    version... - This way I coded a complete software-installer, that runs
    either as a Tcl/Tk-Script with GUI, or as bash-script, when no Tcl is
    available. - I really would like to have something like that for python,
    but I did not find a way to achieve that, yet.

    Regards
    Stephan
     
    Stephan Kuhagen, Aug 9, 2006
    #9
  10. On 2006-08-09 at 08:02:03 (+0200), Stephan Kuhagen wrote:
    > Don't yell at me for bringing in another language, but I really like the
    > trick, Tcl does:
    >
    > > #!/bin/sh
    > > # The next line starts Tcl \
    > > exec tclsh "$0" "$@"

    >
    > This works by the somewhat weird feature of Tcl, that allows comments to be
    > continued in the next line with "\" at the end of the comment-line. It
    > looks unfamiliar, but has several advantages, I think. First it's really
    > VERY unlikely, that there is no /bin/sh (while I found systems with
    > different places for env), and you can add some other features at or before
    > the actual call of the interpreter, i.e. finding the right or preferred
    > version... - This way I coded a complete software-installer, that runs
    > either as a Tcl/Tk-Script with GUI, or as bash-script, when no Tcl is
    > available. - I really would like to have something like that for python,
    > but I did not find a way to achieve that, yet.


    You could use:
    #!/bin/sh
    """exec" python "$0" "$@"""
    :)

    --
    __ ____________________________________________________________________
    | \/ | Micha³ Bartoszkiewicz <> | _ )
    | |\/| | GG:2298240 | _ \
    |_| |_|_For all resources, whatever it is, you need more. [RFC1925]_|___/
     
    =?iso-8859-2?Q?Micha=B3?= Bartoszkiewicz, Aug 9, 2006
    #10
  11. Michał Bartoszkiewicz wrote:

    > #!/bin/sh
    > """exec" python "$0" "$@"""


    Wow, cool... I like that!

    Stephan
     
    Stephan Kuhagen, Aug 9, 2006
    #11
  12. Stephan Kuhagen wrote:

    > Michał Bartoszkiewicz wrote:
    >
    >> #!/bin/sh
    >> """exec" python "$0" "$@"""

    >
    > Wow, cool... I like that!


    Only someone genuinely fond of the Tcl hack could ...

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
    No man who needs a monument ever ought to have one.
    -- Nathaniel Hawthorne
     
    Erik Max Francis, Aug 9, 2006
    #12
  13. Erik Max Francis wrote:

    >>> #!/bin/sh
    >>> """exec" python "$0" "$@"""

    >>
    >> Wow, cool... I like that!

    >
    > Only someone genuinely fond of the Tcl hack could ...


    True, I admit, I'm a Tcl-Addict... But I really love Python too for many
    reasons. But I miss features and tricks in both languages that I have in
    the other...

    Interleaving the script-language with shell-scripting was one of them. So
    I'm a little bit happier with Python now... ;-)

    Stephan
     
    Stephan Kuhagen, Aug 9, 2006
    #13
  14. John Salerno

    ZeD Guest

    Stephan Kuhagen wrote:

    >> #!/bin/sh
    >> """exec" python "$0" "$@"""

    >
    > Wow, cool... I like that!


    yeah, but...

    $ cat test.py
    #!/bin/sh
    """exec" python "$0" "$@"""

    print "Hello, world"
    $ file test.py
    test.py: Bourne shell script text executable

    --
    Under construction
     
    ZeD, Aug 9, 2006
    #14
  15. ZeD wrote:

    > print "Hello, world"
    > $ file test.py
    > test.py: Bourne shell script text executable


    Yes, the same happens with all Tcl-Scripts. I like to see this as a bug in
    "file", not in the scripting...

    Stephan
     
    Stephan Kuhagen, Aug 9, 2006
    #15
  16. Stephan Kuhagen wrote:

    > Yes, the same happens with all Tcl-Scripts. I like to see this as a bug in
    > "file", not in the scripting...


    How does that make sense? `file` cannot possibly understand the
    semantics of files at that level, at least not without executing them.
    And that's exactly what you _don't_ want to do when you're using `file` ...

    The file _is_ a /bin/sh executable. You're just having that /bin/sh
    executable run something else -- how could `file` figure that out
    without a ridiculously complicated set of rules that rise to the level
    of a sh interpreter -- thereby, defeating the purpose?

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
    Only those who dare to fail greatly can ever achieve greatly.
    -- Robert F. Kennedy
     
    Erik Max Francis, Aug 9, 2006
    #16
  17. John Salerno

    Tobias Brox Guest

    [Erik Max Francis
    > How does that make sense? `file` cannot possibly understand the
    > semantics of files at that level, at least not without executing them.
    > And that's exactly what you _don't_ want to do when you're using `file` ...


    This is very off-topic, but if it's fairly common to begin tcl-scripts
    as a /bin/sh-file with "exec tcl" at one of the first lines, I think
    "file" ought to be able to recognize it.

    """exec" python is clearly an obscure hack not used by many, so I
    don't see why "file" should ever recognize that :)

    --
    Tobias Brox, 69°42'N, 18°57'E
     
    Tobias Brox, Aug 9, 2006
    #17
  18. Tobias Brox wrote:

    > This is very off-topic, but if it's fairly common to begin tcl-scripts
    > as a /bin/sh-file with "exec tcl" at one of the first lines, I think
    > "file" ought to be able to recognize it.
    >
    > """exec" python is clearly an obscure hack not used by many, so I
    > don't see why "file" should ever recognize that :)


    The point is, they're all part of the same tactic -- the particulars of
    sh. Special casing each one is a task without an end. People will come
    up with variants that will do the right thing but foil `file`,
    intentionally or unintentionally -- just as we've seen in this thread.

    The right way to approach this with `file` is to acknowledge that such
    tricks are inherently sh-specific and leave it identified as a sh file.
    Because that is, of course, exactly what it is.

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
    Only those who dare to fail greatly can ever achieve greatly.
    -- Robert F. Kennedy
     
    Erik Max Francis, Aug 9, 2006
    #18
  19. Tobias Brox wrote:

    > This is very off-topic,


    Sorry for starting that...

    > but if it's fairly common to begin tcl-scripts
    > as a /bin/sh-file with "exec tcl" at one of the first lines, I think
    > "file" ought to be able to recognize it.
    >
    > """exec" python is clearly an obscure hack not used by many, so I
    > don't see why "file" should ever recognize that :)


    That's what I meant. It is okay for a Python-script not to be recognized by
    "file" that way, it is enough that I can do it, if I need to. But file
    should recognize this for Tcl, because it is common there. And if it needs
    to work for Tcl only, one can construct a simple mechanism for "file" to
    check this.

    Stephan
     
    Stephan Kuhagen, Aug 9, 2006
    #19
  20. John Salerno

    ZeD Guest

    Erik Max Francis wrote:

    > The file _is_ a /bin/sh executable. You're just having that /bin/sh
    > executable run something else -- how could `file` figure that out
    > without a ridiculously complicated set of rules that rise to the level
    > of a sh interpreter -- thereby, defeating the purpose?


    but...

    $ cat test.py
    #!/usr/bin/env python

    print "Hello, world"
    $ file test.py
    file.py: a python script text executable

    following what you said, test.py is a /usr/bin/env script, not a python one.

    --
    Under construction
     
    ZeD, Aug 9, 2006
    #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,627
    Erik Max Francis
    Nov 10, 2003
  2. Adriano Ferreira
    Replies:
    9
    Views:
    580
    Mike Meyer
    Dec 3, 2005
  3. Yves Dorfsman

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

    Yves Dorfsman, May 2, 2008, in forum: Python
    Replies:
    27
    Views:
    2,011
    Tim Roberts
    May 10, 2008
  4. anne001
    Replies:
    1
    Views:
    478
  5. Gilles
    Replies:
    7
    Views:
    563
    Matej Cepl
    Sep 30, 2012
Loading...

Share This Page