Re^2: shebang anomaly

Replies are listed 'Best First'.
Re^3: shebang anomaly by huck (Prior) on Apr 19, 2018 at 00:00 UTC
https://stackoverflow.com/posts/4304187/revisions The shebang line has never been specified as part of POSIX, SUS, LSB or any other specification. AFAIK, it hasn't even been properly documented. There is a rough consensus about what it does: take everything between the ! and the \n and exec it. The assumption is that everything between the ! and the \n is a full absolute path to the interpreter. There is no consensus about what happens if it contains whitespace. 1 Some operating systems simply treat the entire thing as the path. After all, in most operating systems, whitespace or dashes are legal in a path. 2 Some operating systems split at whitespace and treat the first part as the path to the interpreter and the rest as individual arguments. 3 Some operating systems split at the first whitespace and treat the front part as the path to the interpeter and the rest as a single argument (which is what you are seeing). 4 Some even don't support shebang lines at all. Thankfully, 1. and 4. seem to have died out, but 3. is pretty widespread, so you simply cannot rely on being able to pass more than one argument.	[reply]
Re^4: shebang anomaly by QM (Parson) on Apr 19, 2018 at 09:18 UTC
Option 3 is much like MS DOS and its successors: make every program parse its own command line. Given that quoting in DOS is so difficult, most people don't try to write perl one-liners there. (Granted, it's hard enough in *shell sometimes.) -QM -- Quantum Mechanics: The dreams stuff is made of	[reply]
Re^3: shebang anomaly by pryrt (Abbot) on Apr 19, 2018 at 13:54 UTC
I don't know if you ever gathered this from the other replies, but from choroba's "interpreter and parameter" and your "in both of those example shebangs, I cannot have any arguments" shows that, at least originally, you didn't understand. In the shebangs `#!/usr/bin/env perl -w ##!/usr/bin/env perl -wd` [download] The "/usr/bin/env" is the interpreter, and "perl -w" or "perl -wd" is the single parameter (argument). Because it's one entity, then some versions of `env` will try to run "perl -w", and doesn't find anything to run that's P E R L SPACE DASH W as the name. (the same as you might get on other systems if you tried `/usr/bin/env 'perl -w'` or `/usr/bin/env 'perl\ -w'`.)	[reply] [d/l] [select]
Re^3: shebang anomaly by bliako (Abbot) on Apr 19, 2018 at 09:46 UTC
Apart from all the examples given, there is a script in that page called "cmd" which allegedly will solve your problem by using: `#!cmd /usr/bin/env perl -w`. However, unless I am doing something wrong, it does not work for me. Although it should because what it does is straight-forward: breaks the command line and spawns yet another perl process with these args and your actual perl script. Maybe you will have better luck than me if you were to try having two shell scripts `perlw.sh` and `perlwd.sh` calling perl differently?	[reply] [d/l] [select]
Re^4: shebang anomaly by perlboy_emeritus (Scribe) on Apr 20, 2018 at 15:27 UTC
I contacted the maintainers of GNU coreutils of which env is a component and the answer I got really pissed me off, so I am forced to write my own env for use in debian (env behaves as expected in macOS). Printing the environment is the least difficult of what env does. That can be done with six lines of C, as in: `#include <stdio.h> int main(int argc, char argv, char envp) { while (*envp++) { printf("%s\n", envp[-1]); } }` [download] The more challenging part, or parts, is the other things that env does and to make it work the same whether it is called from the command line or as a shebang. I subscribe to the principle of "least surprise", as in this article: `http://www.faqs.org/docs/artu/ch11s01.html` I'll start with the code in cmd, as reported by choroba in an earlier post and go from there. It is fairly obvious to me that a well-behaved env could be implemented in any of C, bash or Perl. I might try them all, just to explore the possibilities. The GNU coreutils team should learn some humility, since a utility program's purpose is to enable users to do what they want to do, not assert some arrogant notion of "not-invented-here." I maintain that GNU env is either stupid or broken because it does not behave in a shebang the way it does when called from a command line. These two methods of invocation should not produce different results, no matter how aggressively someone asserts the program behaves correctly.	[reply] [d/l] [select]
Re^5: shebang anomaly by Anonymous Monk on Apr 20, 2018 at 16:51 UTC
So you want an `env` that works in a DWIM manner? How should it detect whether it was invoked from command line or from shebang? Note that it is the OS that passes a single argument to `env`. To rectify this, you'd have to change the way OS behaves. FWIW, Linux supports custom executable formats (binfmt_misc). You could actually hack up a fancy ld-linux.so that is shebang capable, and arrange this to handle your scripts as well. But then you'd have to decide how to parse/split the argument string: just split it at whitespace, or use shell escaping rules? Which shell? All in all, that's a horrible can of worms, which is probably why the shebang is as it is today. If you absolutely need a perl environment that is predictable and reliable, then the program path is the least of your worries. You'd most likely bundle your own perl and modules in that case, and know the path of your binaries.	[reply]
Re^6: shebang anomaly by perlboy_emeritus (Scribe) on Apr 20, 2018 at 20:33 UTC
Re^7: shebang anomaly by huck (Prior) on Apr 20, 2018 at 22:19 UTC
Some notes below your chosen depth have not been shown here
Re^5: shebang anomaly by bliako (Abbot) on Apr 20, 2018 at 18:51 UTC
Atta(perl)boy!!! But beware the can of worms Anonymous Monk already warned you about, re: the breaking of the command line, shell escapes and nested quotes.	[reply]