[Tutor] Re: python from shell

Thu, 11 Jul 2002 10:55:35 -0500

--7gGkHNMELEOhSGF6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 10, 2002 at 12:35:09PM +0200, lumbricus@gmx.net wrote:
| > On Tue, Jul 09, 2002 at 09:18:25AM -0500, SA wrote:
|=20
| [ snip ]
|=20
| > Here's the difference :
| >=20
| > /usr/bin/env is a program that searches the $PATH to find the program
| > given as it's first argument.  Then it exec's it on the input
| > (script).
| >=20
| > Using /usr/bin/env means that your script will automagically run on
| > any person's system *IFF* the 'python' found first in the $PATH is the
| > one you wanted to use.  It also means (due to limitations in
|                                                 ^^^^^^^^^^^
| what do you mean?

See below.

| > linux/bash)
|   ^^^^^^^^^^
| now which one?

I don't remember which.

| > that you can't pass any arguments to python itself (such
| > as -u or -OO).
|=20
| From 'man env' on OSF1
| (no matter which shell ;-)

Ok, same here.

=2E..
| It works for me.

$ cat env.py
#!/usr/bin/env python -OO

print "Starting"
if __debug__ :   # remember, this is false when optimization is turned on
    print "running with __debug__"
print "That's all folks."

$ ./env.py
/usr/bin/env: python -OO: No such file or directory

$

Oh, I just expected it to not pass the -OO argument.

True.  At least you won't send me a bug report saying "your script has
invalid syntax" when the real problem is you ran it with the wrong
interpreter :-).

| > For example, on a debian woody system, /usr/bin/python is a symlink to
| > /usr/bin/python2.1, and it is also possible for the user to have
| > /usr/bin/python2.2 as well.  On a RH 7.x system, 'python' (is it in
| > /usr/bin ?) is version 1.5 wherease 'python2' is version
| > 2.<something>.  Using the env trick will yield different results on
| > different systems, and using the full path isn't compatible with all
| > systems.
|=20
| ACK
| =20
| > Pay your money and take your choice :-) (as one of my profs likes to sa=
y)
|=20
| But env(1) has the advantage that it sets the environment as the
| command (python) needs it - PYTHONPATH, PYTHONHOME or the like.

It will set the environment only if it inherited the right environment
from the parent process.  Otherwise (eg when run from apache as a CGI
script) it won't.  Thus this argument doesn't have any real meaning.

| > I choose to use the absolute path and explicitly specify the version I
| > want.  Then again, I also use debian and for debian-packaged programs
| > that is also the Policy.
|=20
| But this fails, if the specified version isn't there.=20

True.

| I'd prefer env(1).

That would still fail on your system, because I would end up writing
    #!/usr/bin/env python2.2
or
    #!/usr/bin/env python2.1
so that I could control which version I ran, but your RH (or whatever)
system might only have 'python' or 'python2'; and your 'python' or
'python2' might not be the right version for my script.  (eg if your
python2 is version 2.1 but I used 2.2 features)

I prefer standardization :-).  If everyone named their python in the
same way ...

(FYI that's part of what I like about debian -- they develop a Policy
for things like this to allow the most flexibility for the end user
while eliminating variations like path-to-python that prevent people
from writing portable scripts)

-D

--=20
=20
One OS to rule them all, one OS to find them,
One OS to bring them all and in the darkness bind them,
In the Land of Redmond, where the Shadows lie.
=20
http://dman.ddts.net/~dman/

--7gGkHNMELEOhSGF6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj0tqncACgkQO8l8XBKTpRT9iACeMGoc7+rTErtzvrO7ox1ZExDy
pX0An2KgGEuxUbck/WUgAyUZjOOWebFR
=ZLI9
-----END PGP SIGNATURE-----

--7gGkHNMELEOhSGF6--