/usr/bin/env: python: No such file or directory

Quinn Dunkan quinn at groat.ugcs.caltech.edu
Wed Dec 19 21:14:33 EST 2001

On Tue, 18 Dec 2001 20:24:02 GMT, Michael Hudson <mwh at python.net> wrote:
>Fernando Pérez <fperez528 at yahoo.com> writes:
>> It is NOT practical to expect users to write their scripts using
>> #!/usr/bin/env python2, simply because that's a weird, redhat only
>> default that breaks everywhere else. And what of code they download?
>> Now they have to manually inspect every script they get from the web
>> to replace python->python2? That's plain moronic.
>No, those scripts should use distutils, which will get it right when
>it installs them.
>$ python2 setup.py install --prefix=$HOME 
>Everyone should use distutils.  All the time.

It seems to me like a move from "install with cp" to "install with this
complicated system that gropes around your system, mangles the files, etc. and
then does cp" is a step backwards.

I don't know how much time I've wasted fighting with too-clever install
scripts, broken Makefile-mazes that want to rebuild the world every time, GNU
configure picking broken settings, setup.py deciding to start using
'gcc -shared' to make shared objects on SunOS when only 'gcc -G' works and
what do you edit to change that, and programs which generate perl scripts
which generate imakefiles which generate makefiles which generate shell
scripts which sed out a bunch of magic tokens in configuration files, which
then breaks, etc.  etc. when all I really needed was 'cc -c *.c -o program;
cp program /usr/local/bin'.  Now, of course, this ideal is naive in a world of
13 flavors of unix misimplementing broken POSIX functions in different ways
and compilers with two pages of command line flags and mazes of shared
libraries.  But that's the C world.

The way I see it, people should use distutils when they have to, but use plain
/bin/cp when they can.  I mean no disrespect to the distutils developers, I'm
sure it's quite handy when you want to build dynamically loaded C extensions
that rely on a few random shared libraries that may or may not have the right
functions and who knows where the system is hiding them, etc.

Besides, what if distutils goes and changes all your shebangs to python2 but
your python scripts are network mounted?

More information about the Python-list mailing list