Proper shebang for python3

[Cameron Simpson]

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>