From: "Theo de Raadt" Subject: Re: Support for /usr/bin/env -S (kind of) To: Manuel Giraud Cc: tech@openbsd.org Date: Fri, 18 Jul 2025 10:36:29 -0600 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 wrote: > "Theo de Raadt" writes: > > > Manuel Giraud wrote: > > > >> Florian Obser 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