3 ms·

The typical use case for env -S is a script passing arguments to the interpreter (#!/usr/bin/env -S interp --foo → interp --foo ./scriptname), and the user can

The typical use case for env -S is a script passing arguments to the interpreter (#!/usr/bin/env -S interp --foo → interp --foo ./scriptname), and the user can always pass arguments to the script (./scriptname --bar → interp --foo ./scriptname --bar). But why would a script ever need to use a shebang to pass an argument like --bar to itself? Can’t it just modify its own argv, or act as if it had? (I found your message at https://lists.gnu.org/archive/html/coreutils/2017-05/msg00021.html https://lists.gnu.org/archive/html/coreutils/2017-05/msg0002... that claims > It is useful because it allows the hash bang to specify some arguments after the script (which could be arguments belonging to the script rather than to the interpreter, for instance). but doesn’t really explain why the script itself would want to specify that.) In any case, compatibility is important here, in order for it to be possible to write cross-platform scripts.

kazinator 4y ago
Here is a use case not involving the motivation to pass canned options passed to the script. Suppose that the interpreter is such that the script name must be passed as an option. For instance, Awk implementations are like this: awk -f <script> The problem is that this kind of option is allowed to be followed by more options. awk -f <script> -Z # error under GNU awk: -Z is an invalid option See where this is headed? If we have #!/usr/bin/awk -f awk script here and we call this as $ ./script -Z it will pass that option to Awk. But the script wanted to handle that option! $ ./script -- -Z # process -Z as argument to the script and wouldn't it be nice if we could hide this "--" argument in the hash bang? With my proposal you could do that: #!/usr/bin/env :awk:-f:{}:-- Now speaking of Awk, GNU awk has solved this particular problem itself. It has the option -E/--exec which works like -f, but is the last option to be processed. (Any of these kinds of issues can be solved locally for a given interpreter, if you control its implementation.)

kazinator 4y ago

Here is a use case not involving the motivation to pass canned options passed to the script. Suppose that the interpreter is such that the script name must be passed as an option. For instance, Awk implementations are like this: awk -f <script> The problem is that this kind of option is allowed to be followed by more options. awk -f <script> -Z # error under GNU awk: -Z is an invalid option See where this is headed? If we have #!/usr/bin/awk -f awk script here and we call this as $ ./script -Z it will pass that option to Awk. But the script wanted to handle that option! $ ./script -- -Z # process -Z as argument to the script and wouldn't it be nice if we could hide this "--" argument in the hash bang? With my proposal you could do that: #!/usr/bin/env :awk:-f:{}:-- Now speaking of Awk, GNU awk has solved this particular problem itself. It has the option -E/--exec which works like -f, but is the last option to be processed. (Any of these kinds of issues can be solved locally for a given interpreter, if you control its implementation.)