On 22Jul2019 21:14, Eli the Bearded <*@eli.users.panix.com> wrote:
In comp.lang.python, Tim Daneliuk <i...@tundraware.com> wrote:
On 7/20/19 1:20 PM, Chris Angelico wrote:
> On Sun, Jul 21, 2019 at 4:13 AM Michael Speer <knome...@gmail.com> wrote:
>> You may want to use `#!/usr/bin/env python3` instead.
I no longer have one to verify, but I recall Solaris boxen used /bin/env
not /usr/bin/env.
That is my recollection too. A pain point. To the point that I'd hand
make a /usr/bin/env symlink.
Why _any_ modern system has anything other than /bin in the base install
escapes me. In the distant past /sbin and a distinct /usr with its own
bin had their values, but these days? Bah!
(I'm not complaining about /usr/local/bin here - keeping added stuff
distinct from the vendor/distributor stuff is very valuable.)
So, no, do NOT encode the hard location - ever. Always use env to
discover the one that the user has specified.
But wait, you just hard coded the location of env...
Yeah. Too many boots, too many straps.
The only exception is
/bin/sh which - for a variety of reasons - can reliably counted upon.
BZZZZ! Fully half of my work porting trn4 to my cellphone was fixing all
the places that ancient build system believed /bin/sh was the name of
sh. In that environment (Termux shell on an Android phone) the location
is /data/data/com.termux/files/usr/bin/sh (and env is also in
/data/data/com.termux/files/usr/bin hahaha).
I'd do the symlink thing there too, if feasible. (Counterpoint: I've a
DVR here where changes to / don't survive a reboot and there's no
/etc/rc.local like file which survives a reboot either.)
POSIX systems have a /bin/sh. I would move heaven itself to ensure this.
Even on more traditional environments -cough-Solaris-cough- /bin/sh may
exist but be so ancient as to break things that work elsewhere. "^" as
a synonym for "|", is a noteworthy gotcha.
Aye. I still quote ^ in my scripts to this day for this reason. But
then, I learnt shell programming on V7 UNIX, well older than Solaris.
Figuring out where things are on the user's path is a laudable goal, but
do it only at install time, not run time, for consistent runs.
Perhaps. Consistent runs require consistent environments. That often
includes executables.
Cheers,
Cameron Simpson <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
