Re^3: shebang anomaly

[bliako]

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?

[perlboy_emeritus]

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]);
    }
}

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.

[Anonymous Monk]

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.

[perlboy_emeritus]

I appreciate your insights but you're missing the point. I don't intend to reinvent the wheel and write a new shell. What I need and what I want is to execute Perl scripts with the same shebang in either macOS or Linux, or even Windows XP with the help of MKS Toolkit. Why, because I have multiple Perls installed in each OS and multiple OSes and all share the same Perl source. So, I don't want to have to edit scripts originating in macOS with a #! /usr/bin/env perl -w shebang to #! /usr/bin/perl -w just so they run in debian. perlbrew does this now with nothing more than a fairly sophisticated .bashrc. The cmd code I downloaded that choroba pointed me to does almost what I want now. It only omits actually printing the environment but that is trivial to fix. Whenever this cmd/env is called without any arguments it can print the environment, the %ENV hash. So, you seem to be hinting that Linux is less capable than macOS (just another *NIX), and/or the maintainers of GNU coreutils are incapable of doing or unwilling to do what Apple engineers did and can do? Why do you think this works in macOS and not Linux, other than the maintainers of env don't want to do it? Are fork and exec in Darwin different from their counterparts in Linux? Or BSD, or AIX, or Next, or any other UNIX or UNIX-like OS?

[bliako]

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.