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

[John Salerno]

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?

 

[Steven Bethard]

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

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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

 

[skip]

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

 

[John Salerno]

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.

 

[Erik Max Francis]

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]

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.)

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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

 

[Stephan Kuhagen]

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

 

[=?iso-8859-2?Q?Micha=B3?= Bartoszkiewicz]

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


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" "$@"""

 

[Stephan Kuhagen]

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

Wow, cool... I like that!

Stephan

 

[Erik Max Francis]

Wow, cool... I like that!

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

 

[Stephan Kuhagen]

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

 

[ZeD]

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

 

[Stephan Kuhagen]

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

 

[Erik Max Francis]

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?

 

[Tobias Brox]

[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

 

[Erik Max Francis]

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.

 

[Stephan Kuhagen]

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

 

[ZeD]

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.