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

[Carl Banks]

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

On May 2, 11:07 am, "D'Arcy J.M. Cain" <da...@druid.ne twrote:

On Sat, 03 May 2008 00:43:02 +1000
>
Ben Finney <bignose+hate s-s...@benfinney. id.auwrote:

Roy Smith <r...@panix.com 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 <da...@druid.ne t | Democracy is three wolveshttp://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

[Erik Max Francis]

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

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.

Yes, and that's the reason the env form is preferred. If someone --
either the system administrator, or the user environment, or the person
executing the program on the fly -- has changed the PATH, they did it
for a reason. If /usr/local/bin is in the PATH before /usr/bin, then
that is a deliberate choice (whether system-wide or not) to prefer
executables in /usr/local/bin to those in /usr/bin, and that is being
done for a very conscious reason. Which is why the PATH exists in the
first place, and why invoking the script with env is preferable.


--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis

[Robert Kern]

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

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

[Ben Finney]

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

"D'Arcy J.M. Cain" <darcy@druid.ne twrites:

On Sat, 03 May 2008 00:43:02 +1000
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

Roy Smith <roy@panix.comw rites:

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.

Nor was I. Thanks for the condescension and straw-man attacks, but...

I do believe I am done with this thread.

That's a relief.

--
\ “He that would make his own liberty secure must guard even |
`\ his enemy from oppression.” —Thomas Paine |
_o__) |
Ben Finney

[Gabriel Genellina]

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

En Fri, 02 May 2008 12:07:55 -0300, D'Arcy J.M. Cain <darcy@druid.ne t>
escribió:

On Sat, 03 May 2008 00:43:02 +1000
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

>Roy Smith <roy@panix.comw rites:

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

[Ben Finney]

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

Ben Finney <bignose+hate s-spam@benfinney. id.auwrites:

The shebang line (the initial line of the file beginning with "#!")
takes advantage of OS kernels that determine how to execute a file
based on the first few bytes of the file. The shebang line tells the
kernel that this file should be executed by passing it as input to a
process started by another command.
>
The specified command takes the form of a fully-qualified file path,
and zero or one arguments to the program. That command is then
executed by the kernel, and the Python program file is passed as
input to the resulting process.

As was pointed out later in the thread, this description is partially
untrue. The program isn't passed as input to the interpreter.

Instead, the path to the program is appended as a command-line
argument to the interpreter. Thus the kernel starts a command of the
form:

<word after the shebang<optiona l single argument after the first word<path to the program>

Examples:

filename: /home/foo/bar.py
shebang line: #! /usr/bin/python
command line invoked: /usr/bin/python /home/foo/bar.py

filename: /home/foo/Makefile
shebang line: #! /usr/bin/make -f
command line invoked: /usr/bin/make -f /home/foo/Makefile

For more information on shebang processing, see
<URL:http://foldoc.org/index.cgi?sheba ngfor a basic description, and
<URL:http://www.in-ulm.de/~mascheck/various/shebang/for lots of gory
detail.

--
\ "There's no excuse to be bored. Sad, yes. Angry, yes. |
`\ Depressed, yes. Crazy, yes. But there's no excuse for boredom, |
_o__) ever." -- Viggo Mortensen |
Ben Finney

[Torsten Bronger]

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

Hallöchen!

Gabriel Genellina writes:

[...]
>
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...

Well, Python-list is tunnelled to Usenet. Welcome here. ;-)

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: bronger@jabber. org
(See http://ime.webhop.org for further contact info.)

[Lou Pecora]

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

In article <A72dnRnGiotPr4 bVnZ2dnUVZ_qTin Z2d@visi>,
Grant Edwards <grante@visi.co mwrote:

On 2008-05-02, D'Arcy J.M. Cain <darcy@druid.ne twrote:

On Sat, 03 May 2008 00:44:00 +1000
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

"D'Arcy J.M. Cain" <darcy@druid.ne twrites:
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

[Aahz]

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

In article <mailman.494.12 09791508.12834. python-list@python.org >,
Gabriel Genellina <gagsl-py2@yahoo.com.a rwrote:

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

http://www.netfunny.com/rhf/jokes/91q3/usolym.html

--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

Help a hearing-impaired person: http://rule6.info/hearing.html

[andrej.panjkov@climatechange.qld.gov.au]

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

At our site we run IRIX, UNICOS, Solaris, Tru64, Linux, cygwin and
other unixy OSes.

We have python installed in a number of different places:
/bin/python
/usr/local/bin/python
/usr/bin/python
/opt/freeware/Python/Python-2.5.1/bin/python
~mataap/platform/python/python-2.5.1

So I cannot assume a single location for python. Nor for any other
tool, really. Bash for example. It may indeed be in /usr/bin on many
systems, on many others it is not.

Note the version specific install points. This allows us to switch
over easily to different versions, and keep older versions in case
they are needed. We can test new versions before cutting over to them
operationally. (This matters for tools that are still changing, like
python or bash.)

We use the very handy 'modules' package (not python modules, not
fortran modules) to adjust our paths and environment variables as
needed.

Some of the install points are determined by policy, or historical
constraints, or hardware limits, or file system layout.

Now it is true that it is easy to edit a single script to change the
hashbang line. It is not easy to change several hundred scripts, on
different machines. It is easy to adjust the environment to point to
the right python path, and have all your scripts pick it up
automatically.

Use /usr/bin/env. If env is not in /usr/bin, put a link to it there.

[Banibrata Dutta]

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

On 5/6/08, andrej.panjkov@ climatechange.q ld.gov.au
<andrej.panjkov @climatechange. qld.gov.auwrote :

At our site we run IRIX, UNICOS, Solaris, Tru64, Linux, cygwin and
other unixy OSes.
>
We have python installed in a number of different places:
/bin/python
/usr/local/bin/python
/usr/bin/python
/opt/freeware/Python/Python-2.5.1/bin/python
~mataap/platform/python/python-2.5.1
>
So I cannot assume a single location for python. Nor for any other
tool, really. Bash for example. It may indeed be in /usr/bin on many
systems, on many others it is not.
>
Note the version specific install points. This allows us to switch
over easily to different versions, and keep older versions in case
they are needed. We can test new versions before cutting over to them
operationally. (This matters for tools that are still changing, like
python or bash.)
>
We use the very handy 'modules' package (not python modules, not
fortran modules) to adjust our paths and environment variables as
needed.
>
Some of the install points are determined by policy, or historical
constraints, or hardware limits, or file system layout.
>
Now it is true that it is easy to edit a single script to change the
hashbang line. It is not easy to change several hundred scripts, on
different machines. It is easy to adjust the environment to point to
the right python path, and have all your scripts pick it up
automatically.

Looks reasonable thing to do...

>
Use /usr/bin/env. If env is not in /usr/bin, put a link to it there.

So why not put symlink to Python over there on all machines, if we can
put one (or env itself) there ?

--
regards,
Banibrata

http://www.linkedin.com/in/bdutta

[Wojciech Walczak]

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

2008/5/6, Banibrata Dutta <banibrata.dutt a@gmail.com>:

Use /usr/bin/env. If env is not in /usr/bin, put a link to it there.

>
So why not put symlink to Python over there on all machines, if we can
put one (or env itself) there ?

To avoid linking all the rest of interpreters like perl, ruby, lua and dozens
of others.

--
Regards,
Wojtek Walczak

http://www.stud.umk.pl/~wojtekwa/

[Ben Finney]

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

"Wojciech Walczak" <wojtek.gminick .walczak@gmail. comwrites:

2008/5/6, Banibrata Dutta <banibrata.dutt a@gmail.com>:

Use /usr/bin/env. If env is not in /usr/bin, put a link to it there.

So why not put symlink to Python over there on all machines, if
we can put one (or env itself) there ?

>
To avoid linking all the rest of interpreters like perl, ruby, lua
and dozens of others.

The argument was being made from "thousands of scripts". Isn't "dozens
of symlinks" better?

--
\ "It is difficult to get a man to understand something when his |
`\ salary depends upon his not understanding it." —Upton |
_o__) Sinclair, 1935 |
Ben Finney

[Wojciech Walczak]

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

2008/5/6, Ben Finney <bignose+hate s-spam@benfinney. id.au>:

So why not put symlink to Python over there on all machines, if
we can put one (or env itself) there ?

To avoid linking all the rest of interpreters like perl, ruby, lua
and dozens of others.

The argument was being made from "thousands of scripts". Isn't "dozens
of symlinks" better?

I think that depending on /usr/bin/env is more farsighted and saves some future
headaches. Creating links in /usr/bin/ means, that you have to change them
whenever you update your software (e.g. any of your many interpreters ;-)).
Changing the "#!/usr/bin/python" into "#!/usr/bin/env python" means that you do
your job once, and you can sleep well. It also is more portable.

How was it in perl?
perl -p -i -e 's/#\!\/usr\/bin\/python/#\!\/usr\/bin\/env python/' *.py

Funny thing, I have just ls'ed /usr/bin/python on my system:
$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 24 2007-11-16 14:02 /usr/bin/python ->
/usr/local/bin/python2.5

:-)

--
Regards,
Wojtek Walczak

http://www.stud.umk.pl/~wojtekwa/

[andrej.panjkov@climatechange.qld.gov.au]

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

On May 6, 9:06 pm, Ben Finney <bignose+hate s-s...@benfinney. id.au>
wrote:

"Wojciech Walczak" <wojtek.gminick .walc...@gmail. comwrites:

2008/5/6, Banibrata Dutta <banibrata.du.. .@gmail.com>:

Use /usr/bin/env. If env is not in /usr/bin, put a link to it there.

>

So why not put symlink to Python over there on all machines, if
we can put one (or env itself) there ?

>

To avoid linking all the rest of interpreters like perl, ruby, lua
and dozens of others.

>
The argument was being made from "thousands of scripts". Isn't "dozens
of symlinks" better?
>

It depends on single user vs multi user. We keep multiple versions of
packages because some software requires the older versions. Which
version do we symlink to? What if we simultaneously require access to
two different versions? For example, to keep legacy software going,
or to test updated versions while keeping operational versions
running.
What if we have shared file systems, and we have multiplatform
versions? Python for solaris, python for tru64?

In a sense, we do have dozens of "virtual" links, using the modules
package to adjust paths on the fly. This is more flexible than having
a static symlink in /usr/bin. It allows us to select on a per user,
per process, per script basis, the python we want, version, platform
etc. With a static symlink, every user/process/job gets the same
python, unless you want to flip symlinks around.

Also, every 10 years or so, each platform gets replaced, so we are
replacing platforms here every few years. And we don't always get the
same replacement system. Sure we can go in and touch up all the
scripts. But it just seems so much easier and flexible to tell a
python/bash/other script to use what you get from the path, and set
the paths.

Of course, things are different on a single user desktop system, with
its own filesystems. If you are sure where python is, and you only
have one python, and you don't mind revisiting your scripts and
editing them if things change, by all means hard code the python path
in.

A