Bug in python startup on linux? [Was: Wrong Executable? or something]

[Mats Wichmann]

On 21 Dec 1999 21:47:27 +0100, Bernhard Herzog <herzog at online.de>
wrote:

>Siggy Brentrup <bsb at winnegan.de> writes:
>
>> Clarence Gardner <clarence at beach.silcom.com> writes:
>> 
>> > This is a problem I've seen on many linux systems.  They're all RedHat or
>> > Mandrake (extended RedHat).
>> 
>> Same holds for Debian slink aka 2.1
>> 
>> I did a little more testing and found out that results depend on your
>> PATH setting.
>> 
>> Calling scripts with an empty PATH gives the expected results
>[snip proof]
>> I suspect a bug in the python startup routine, since sys.prefix
>> and sys.exec_prefix are determined at configuration time.
>
>Python tries to initialize sys.path based on the location of the python
>executable. If argv[0] contains no '/' python searches $PATH for the
>executable and starts from there.
>
>On Linux it seems that a program called by the #! mechanism only gets
>the basename of the file in argv[0], i.e. there's no '/' and therefore
>python searches through the directories in $PATH, so it might get the
>wrong one.
>
>I'm not sure whether this is to be considered a bug in Linux or Python,
>but Python could perhaps work around this on a Linux system by using
>/proc/self/exe (which is a symbolic link to the executable of the
>process) as reference when it searches $PATH for the file.

How about not a bug in either?

#! has eluded all efforts to be "standardized" in the UNIX universe.
Hard to say what the correct behavior should be in the absence of
an actual standard.  Since installation of tools is up to the user in
many cases, and there's nothing "wrong" with installing Python
in a completely different place (say, "/opt/bin/" instead of
"/usr/local/bin" - it's just a single change at configure time), a
script with a full pathname is not particularly portable. There's been
some talk of devising a two-level mechanism where a file called
/etc/interpreters or some such contains the full paths to #!
interpereters on the target system, so that #!python would do
the right thing and you don't need  so say - non-portably -
#!/usr/local/bin/python....


Mats Wichmann

(Anti-spam stuff: to reply remove the "xyz" from the
address xyzmats at laplaza.org. Not that it helps much...)