If I squint, I see more unsafe ways this will get used in practice,
than safe ways.

Currently, this cannot be used in any unsafe way because it doesn't
exist.  It fails.

Since it is not a portable or standardized extension, it already cannot be
used in portable code.

Which means currently, to perform this action, people write a *PROPER
SCRIPT* and don't try to push this complicated logic into the #! line
where it quite plausibly does not belong.

When a proper script containing the logic, will also work more
correctly for both use cases:

     sh script  (sh direct execution)

rather than

    ./script

Whereas pushing the logic into the #! line means the sh direct execution
obviously ignores the coding logic placed into the #! line, and thus the
behaviour is different.  My big picture view is that subtle differences
in many subsystems always pile up and eventually subtly create harm.

So how common is this actually, or is it just something someone wished
and they pushed it into Linux and it actually isn't used?

Manuel Giraud <manuel@ledu-giraud.fr> wrote:

> "Theo de Raadt" <deraadt@openbsd.org> writes:
> 
> > Manuel Giraud <manuel@ledu-giraud.fr> wrote:
> >
> >> Florian Obser <florian@openbsd.org> writes:
> >> 
> >> > It kind of misses a diff for the man page.
> >> 
> >> Yes I know but I wanted to try first if this could fly.
> >
> > It won't fly becuase we don't know what it does because you didn't
> > document it.
> 
> Ok.  It is an option present in other implementations that permits to
> have multiple command line options in a shebang script.  Here's what is
> said in the linux manpage:
> 
>      -S, --split-string=S
>               process and split S into separate arguments; used to pass
>               multiple arguments on shebang lines
> 
> For example, one could make the following silly script:
> 
> #!/usr/bin/env -S cat -b -e
> Hello World
> 
> The current env will fail because it will try to execvp the complete
> string "cat -b -e":
> 
> env: cat -b -e: No such file or directory
> 
> I wanted to know if this would fly because here I choose to split the
> string beforehand when argv[1] contain any separators.  I kept the "-S"
> for compatibility with other implementations but, in fact, it does
> nothing.
> -- 
> Manuel Giraud