The case of the supersized shebang

Posted Feb 18, 2019 22:48 UTC (Mon) by rweikusat2 (subscriber, #117920)
In reply to: The case of the supersized shebang by NYKevin
Parent article: The case of the supersized shebang

> Frankly, I agree with the kernel here. Shebang lines are a convenience, and more importantly they're intended for use
> by the (userspace components of the) distro, and are accidentally useful to end users,

https://www.in-ulm.de/~mascheck/various/shebang/4.0BSD_ne...

The assumption that people who aren't "involved with a distro" must be "end users" (who have no business programming anything) is ... interesting ...

The case of the supersized shebang

Posted Feb 19, 2019 1:24 UTC (Tue) by KaiRo (subscriber, #1987) [Link]

IMHO, even assuming that "end users" have no business programming is, erm, interesting, as I thought one point of FLOSS was that *anyone* can start programming and contributing.

The case of the supersized shebang

Posted Feb 19, 2019 9:36 UTC (Tue) by brooksmoses (guest, #88422) [Link] (5 responses)

I think you're misunderstanding NYKevin's point -- he specifically said "writing shebang lines", not "programming".

If you're not writing code that's part a distro's userspace, you should (generally) be writing code to be portable across different distros. (Even if you're an end-user with only one computer, you may well change your distro in the future and want to run your old code.) However, a shebang line is not reliably portable -- to pick an example that I've recently been having pains with, "#!/usr/bin/python2" assumes that your distro has Python version 2 installed in /usr/bin/python2. If you instead have only /usr/bin/python2.7, or /usr/local/bin/python2, or something else, then it doesn't work. And shebangs don't follow the PATH, so you have to specify an absolute path.

In the particular case I was having pains with, the relevant code was in a testsuite, and it would have been much nicer to have Autoconf find the right interpreter and then call it explicitly via something like "$PYTHON testfile.py".

The case of the supersized shebang

Posted Feb 19, 2019 13:48 UTC (Tue) by NAR (subscriber, #1313) [Link] (2 responses)

However, a shebang line is not reliably portable

I guess that's why /usr/bin/env was invented for...

The case of the supersized shebang

Posted Feb 19, 2019 16:36 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link]

Sort-of. It does a PATH seach internally. This may find some perl executable and it may even be the one supposed to execute a particular script. However, it might as well not. perl is a fairly stable execution environment, however, it has its share of "Let's break working stuff because it's just WRONG!" (that it works, presumably :->) people who add essentially random code changes[*] whose purpose doesn't seem to be known to anyone.

[*] Eg, starting with perl 5.16, xs functions can't be loaded via Dynaloader anymore unless a new keyword is added to the existing code. The documentation makes it very clear that loading xs-functions via Dynaloader Is Just Wrong[tm], but there's no positive justification for the change.

The case of the supersized shebang

Posted Feb 19, 2019 16:46 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

No, that is not what /usr/bin/env was invented for. /usr/bin/env was invented for setting up different environment variables - that's why it's called "env."

The case of the supersized shebang

Posted Feb 19, 2019 15:11 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link]

He wrote about "distro developers" vs "end user sticking scripts in ~/bin". This is a false dichotomy which is so false that it's laughable and all features of the system are ultimatively supposed to be useful to users.

*If* you want to run other people's code, don't stick interpeters in /opt/var/local/ultima-thule/lib/bin/asterisk/moff just because this makes perfect sense to you.

The case of the supersized shebang

Posted Feb 19, 2019 17:01 UTC (Tue) by zblaxell (subscriber, #26385) [Link]

> However, a shebang line is not reliably portable

I, for one, would prefer to solve that problem.

i.e. have a namespace that I can reference from portable scripts, like "#!/prefix/org/python/python/2.7.5", where the python installation puts in as many symlinks as required to accurately state the level of backward compatibility achieved.