Proper shebang for python3
Cameron Simpson
cs at cskk.id.au
Sun Jul 21 21:46:56 EDT 2019
On 21Jul2019 15:47, Peter J. Holzer <hjp-python at hjp.at> wrote:
>On 2019-07-21 09:04:43 +1000, Cameron Simpson wrote:
>> I'm with Tim Daneliuk. The environment matters and should be honoured
>> except
>> in extremely weird cases.
>
>I don't think that all the scripts in /usr/bin are extremely weird
>cases.
I think I'd better add some nuance to my stance.
I've no problem with all the scripts shipped from an OS vendor having
#!/usr/bin/python (or whatever fixed path) in them. They have been
released tested against the system python and should _expect_ to run
against it. My position here is that the entire OS distribution
constitutes a working (and via the #! controlled) environment.
But consider third party tools. Including personal tools, but basicly
anything from _outside_ the local system in terms of authorship.
Particularly with a language like Python which is strongly backwards
compatible, they should generally use "#!/usr/bin/env python" (or
python2 or python3 as appropriate, when that matters) so that they can
run in the environment they find themselves in.
1: You can can always execute a script via a specific interpreter
explicitly.
2: If you want to test a script it is easier to provide an environment
that exercises the script in a particular way than to hand patch the
shebang lines on every run/reconfig.
3: If the script (per one of Chris' examples) requires a specific python
such as 3.6, you can always go "#!usr/bin/env python3.6" in the script
to express the target version and provide a executable "python3.6" name
in you environment. I keep a personal ~/bin-local directory for just
this kind of per-host stuff myself, and of course one can do the same
thing in places like venvs or /usr/local/bin etc. And thus _still_ leave
the script itself without a hardwired path.
[...]
>> If you require a specific outcoming, set a specific environment. It
>> is under
>> your control. Control it.
>>
>> For your specific example, "man youtube-dl" _is_ affected by the
>> environment. It honours the $MANPATH variable.
>
>MANPATH is explicitely intended to control man.
>
>But man doesn't fail if you set your PATH to something weird. It will
>still invoke /usr/bin/groff even if that isn't in the PATH.
>(I expected that there is also an environment variable to control that
>but the manpage doesn't mention one).
Heh.
I wrote my own "man" yonks ago for various reasons. Guess what? I expect
to type "man" and get mine most of the time, but type "man" when not me
and get /usr/bin/man (absent weirdness). That applies interactively and
also in scripts.
Same philosophy. Use the command name to express intent and the
environment to choose the implementation of the intent. And so also in
the shebang lines.
>> For Peter J. Holzer, if we must play the "I've been doing this
>> forever" game: I've been sysadmining etc longer than your 25 years and disagree with
>> you.
>
>That's fine. Unlike Tim I don't claim that anybody who disagrees with me
>must be a newbie.
Aye; sorry for the snarkiness. Which is why I'm disagreeing on some
things instead of asserting that you're wrong, because you're not
"wrong".
Cheers,
Cameron Simpson <cs at cskk.id.au>
More information about the Python-list
mailing list