Download raw body.
Support for /usr/bin/env -S (kind of)
On Fri, Jul 18, 2025 at 06:23:45PM +0200, Manuel Giraud 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.
Regardless of -S pros and cons, there is _no way_ you can change the
default behavior of env(1). That would break many usage patterns just
for the sake of adding a workaround for scripts.
In coreutils or FreeBSD env, -S takes a mandatory argument and only
that argument is split. If we add -S, we should follow the same
logic.
Excerpt from genv(1):
SCRIPT OPTION HANDLING
The -S option allows specifying multiple arguments in a script. Running
a script named 1.pl containing the following first line:
#!/usr/bin/env -S perl -w -T
...
Will execute perl -w -T 1.pl
Without the '-S' parameter the script will likely fail with:
/usr/bin/env: 'perl -w -T': No such file or directory
See the full documentation for more details.
Personnally I don't feel strongly about it but I think there is value
in adding -S so that we don't have to write shell wrappers for
non-shell scripts written on other systems (or move those scripts to
genv(1)).
--
jca
Support for /usr/bin/env -S (kind of)