2

I have a test script, e.g. "test.py", and I want to make it so that it executes with a particular environment variable set before the script begins:

#!/usr/bin/env TEST=anything python

print "Hello, world."

Running this normally works as expected:

$ python test.py 
Hello, world.

However, if I run it as a program:

$ chmod +x test.py
$ ./test.py

The string is never printed, instead the execution just stalls and "top" reports a process called "test.py" which is using 100% CPU.

This only happens on my Ubuntu machine, seems to be fine on OS X.

The reason is that eventually I want to make a particular script always run in a 32-bit Python by setting:

#!/usr/bin/env VERSIONER_PYTHON_PREFER_32_BIT=yes python

at the top of the file. However this is a no-go if it means the script won't execute on Linux machines. I found there is a similar effect no matter what the specified environment variable is called. However, if there is no environment variable set:

#!/usr/bin/env python

print "Hello, world."

The script runs just fine:

$ ./test.py 
Hello, world.

Is this a bug in Python or in env, or am I doing something wrong?

Steve
  • 8,153
  • 9
  • 44
  • 91
  • BTW, `VERSIONER_PYTHON_PREFER_32_BIT` is an Apple modification to Python. It doesn't work with other distributions of Python on OS X, for example, the official python.org OS X Pythons. – Ned Deily Apr 18 '12 at 20:20

3 Answers3

3

On Linux,

#!/usr/bin/env TEST=anything python

passes TEST=anything python as one argument to env. So env will not process the argument properly.

The bottom line is you can only put one command after env on the shebang line, all else will at best be ignored.

From the Wikipedia entry on Shebang:

Another portability problem is the interpretation of the command arguments. Some systems, including Linux, do not split up the arguments[24]; for example, when running the script with the first line like,

#!/usr/bin/env python -c

That is, python -c will be passed as one argument to /usr/bin/env, rather than two arguments. Cygwin also behaves this way.

unutbu
  • 842,883
  • 184
  • 1,785
  • 1,677
  • 1
    Thanks, that explains the actual reason this doesn't work, Python-specifics aside. I still don't quite understand why it seems to result in an infinite loop.. – Steve Apr 19 '12 at 16:47
  • I tried it manually, running `env 'TEST=anything python' test.py`, it just results in "No such file or directory." – Steve Apr 19 '12 at 16:48
  • For an explanation about the reason for the infinite loop see: http://stackoverflow.com/a/33128317/110488 – Chen Levy Oct 14 '15 at 14:52
1

I doubt /usr/bin/env VERSIONER_PYTHON_PREFER_32_BIT=yes python is going to run properly.

Instead, try setting the environment variables with Python:

import os

os.environ['VERSIONER_PYTHON_PREFER_32_BIT'] = 'yes'
Blender
  • 289,723
  • 53
  • 439
  • 496
  • That's not going to help if the goal is to launch Python in 32-bit mode. As noted above, `VERSIONER_PYTHON_PREFER_32_BIT` is an Apple-supplied modification to Python. On OS X, `/usr/bin/python` is an Apple-supplied launcher that evaluates that environment variable and a plist to determine which Python version and in what architecture to launch it. – Ned Deily Apr 18 '12 at 20:45
  • Ah, that makes a bit more sense. The shebang isn't of much help in that case. – Blender Apr 18 '12 at 20:47
  • Well, it *does* actually force 32-bit mode as long as `/usr/bin/python` is first on `$PATH` on OS X 10.6+ and you want to use one of the Apple-supplied Pythons. But it doesn't work with other Pythons which get installed on OS X, a common scenario. – Ned Deily Apr 18 '12 at 20:54
0

You'll probably need to forget about VERSIONER_PYTHON_PREFER_32_BIT, at least on Linux. On Mac, you could use a shell wrapper for it.

Then on Linux, you'll probably need to reinvent VERSIONER_PYTHON_PREFER_32_BIT using a small stub python script or bash script or something, hinging on something like the following:

>>> import platform
>>> platform.machine()
'x86_64'
>>> platform.processor()
'x86_64'
user1277476
  • 2,871
  • 12
  • 10