avoiding long paths to interpreter

[Tim Cargile]

Erik Max Francis <max at alcyone.com> wrote in message news:<3E261C26.B6B6FB59 at alcyone.com>...
> Tim Cargile wrote:
> 
> > There is a FAQ 4.63 from python.org regarding this but,
> > as Erik Max Francis has pointed out in this thread, there may be
> > limitations w/r '/usr/bin/env' that may eliminate using it and require
> > use of the following (as the first three lines of a python module
> > that is desired to be run):
> > 
> >   #! /bin/sh
> >   """:"
> >   exec python $0 ${1+"$@"}
> >   """
> 
> This doesn't really resolve the issue; the Python interpreter it invokes
> is still PATH-dependent, which was the problem with /usr/bin/env.


That is correct.  Because

    #! /bin/sh
    """:"
    exec python $0 ${1+"$@"}
    """

was not originally developed to 'resolve' the issue of PATH-dependency
and,
of course, it cannot do so.  It was originally developed because
'/usr/bin/env'
was completly failing because of an excessive number of variables
in the environment that caused 'env' to fail.  It appears as if it's
develpment was a workaround for that situation. The original thread
that I located when researching this issue can be found on
comp.lang.python,
Subject='Once more about #!/usr/bin/env' dated November 9, 1997. 
Courtesy
Sofin Raskin.  Wow, 'Once more...' and that was 1997!

As you have written:

>   The real wart here is that if you have multiple interpreters installed, say,
>   in /usr/bin and /usr/local/bin, then /usr/bin/env picks the python
>   that's associated with your PATH.  This can lead to bad surprises if the
>   script runs in an interactive shell vs., say, a CGI script or a cron
>   job, where the PATHs are almost certain to be far more restrictive,
>   particularly if you have a highly customized interactive shell.

>   Unfortunately, there's truly no magic bullet here when the script itself
>   depends on a certain version of Python.

I'm not so sure that we are that unfortunate.  My submitted
'extensions'
to the above, seminal approach to launching the python interpreter
may, at
least have the answer to selecting either a desired or preferentail
interpreter.
And I don't see why a variation of one of them could not also handle a
restrictive situation of a CGI script or a cron job as well, if there
is
nothing to stop an expansion or override of PATH and/or the heuristic
selection of an absolute path for the interpreter within the script.

Such as this does:

#! /bin/sh
""":
PATH=/usr/local/bin:${PATH}
exec python $0 ${1+"$@"}
"""

And this:

#! /bin/sh
""":"
if [ -x /usr/local/bin/python ];then
   exec /usr/local/bin/python $0 ${1+"$@"}
elif [ -x /usr/bin/python ];then
   exec /usr/bin/python $0 ${1+"$@"}
else
    echo "$0: Cannot find python in /usr/local/bin, /usr/bin" >&2
    exit 2
fi
"""

Perhaps there is not one variation that can handle running the desired
interpreter on all platforms in the World (the magic bullet?), but at
least
it can handle most of them, I would wager.  The only caveat is that
'/bin/ksh'
has to be there and have some resemblence to a Bourne shell
interpreter.