Hi! For a long time, I have been annoyed by distutils behavior concerning "scripts": I always put #!/usr/bin/env python into the first line in order to let the incredibly useful "env" program start the right python version. I know that it is quite evil to hardcode /usr/bin/python or /usr/local/bin/python; I have seen dozens of #! hacks for finding e.g. perl, and I was delighted to find /usr/bin/env, which solves the problem once and for all. (And yes - it is always in /usr/bin/! ;-) ) Now distutils tries to be intelligent and "destroys" my nice #! lines, which can be quite evil in complex setups, e.g. when you share your home directory via NFS (or rsync/unison) between several environments with different python installations. Furthermore, we are using the "module" system here at our university, so that I can dynamically choose between half a dozen python versions ("module" manages your PATH variables). Replacing the python path turns nice, pure python scrips into platform-specific programs as you can see here: meine@kogspc12:~ head -n1 ~/vigra/interactive/build/scripts-2.4/pyterm #!/software/python-2.4.4/SuSE-9.0/bin/python Note the SuSE-9.0 exec-prefix in the path; we are using several Linux and Solaris versions here: meine@kogspc12:~/tmp/vi3build -> ls -1 /software/python-2.4.4/*/bin/python /software/python-2.4.4/SuSE-10.0/bin/python* /software/python-2.4.4/SuSE-9.0/bin/python* /software/python-2.4.4/SunOS-5.8/bin/python* I see that distutils as it is now does the right thing * on Windows systems, * on any system where /usr/bin/env is missing, or * when the source file has a #! with a broken path. What I propose is a minimal invasive change which keeps /usr/bin/env iff it is in the #! line *and* exists on the current system. (A more brave change would be to always use /usr/bin/env if it exists, but I think that is a topic open for discussion.) Attached you'll find a patch which implements this; I did not yet update tests/test_build_scripts.py however. Comments? Ciao, / / /--/ / / ANS