I do not think that _this_ was or will be ever an issue to myself or any system that i have to deal with and i do not see any use for it but i guess somebody else did. Anyway I believe this page is a very nice read on the background and a little history <a href="https://www.in-ulm.de/~mascheck/various/shebang/" rel="nofollow">https://www.in-ulm.de/~mascheck/various/shebang/</a>
This reminds me of one of the _very few_ bits of freebsd userspace that are better than gnu and was only adopted by gnu much later (8.30, the version first in debian buster, I think): `env -S`.<p>`env -S` introduces an option parser/splitter for #!-lines which can do just about whatever you need (however, it will not work around over-long lines like sbang proposes to do)
I've never had this problem, what is the use case? I've only ever used /usr/bin/env or /bin/bash, and can't think of a reason to do anything fancier. You would be hardcoding the full (presumably non standard) path to the interpreter right? Why not just add it to PATH and use env?
The problem with shebangs that I really want to solve is that I often need to edit files on a Windows machine, and then try to run the resulting CR/LF scripts on a Linux machine using a shared filesystem. (Docker, WSL, Vagrant etc...).<p>I'd like to invoke them with just (eg.) ./dostuff.py - Python, Ruby etc... have absolutely no problem running files containing Win-style line-endings. The only issue is that /usr/bin/env complains that it can't find (eg.) "python3\n".<p>Yes, I know I could convert these files with dos2unix, and I also know that I can just invoke the interpreter explicitly - but I'm lazy, and this seems like such a trivial thing to solve that I can't believe it's not been done already.<p>I've taken to actually recompiling /usr/bin/env to strip trailing whitespace from the executable name - but there must be a better solution.
Wouldn’t it be better to standardize format and baseline argument spec, and let the evaluating environment figure out the rest? Formalizing the entry path is something that is now becoming two lines of indirection just to lie to whatever is actually interpreting it. It’s another line of implicit code that’s up to interpretation and can easily diverge.