Re: [PATCH] env: support encoding of args into command.

[Kaz Kylheku (Coreutils)]

On 27.05.2017 08:06, Pádraig Brady wrote:
> Now the FreeBSD env(1) command supports the -S option
> to do splitting much as you've proposed, so I see no need to be 
> different.
> Could you adjust the patch accordingly?

I think it's probably best to avoid copying FreeBSD here. They have
created a mess with too many requirements. Their -S feature
has quitespace delimiting, quoting, escaping of quotes,
C-like character escape sequences: \n, \r, \f, ...
and ${PARAM} environment variable expansion. A little shell
language seems to be brewing inside the FreeBSD env program.
What's it all for?

Yet, for all the "bells and whistles", they are missing the
{} feature to insert the first argument (the name of the script
in hash bang dispatch) among the generated arguments,
something which can't be achieved with any combination of
environment variable substitutions. 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).

Let's look at the delimiting requirement. Using spaces
perpetrates a clever visual ruse. The command line:

    $ /usr/bin/env -S a b c

translates directly to hash bang:

    #!/usr/bin/env -S a b c

the semantics is different, of course; here the string " a b c"
is one argument to -S, subject to splitting. It's
understandable why they have it this way, but I believe
it is fine not to play this sort of trick and make the
mechanism have a visually explicit syntax.

I chose the colon character for a very good reason: it is the
PATH separator. Which means, it doesn't occur the command
argument in any correct usage of env, and is therefore available
as a separator.

I don't envision a need to support quoting the : character
for inclusion in an argument.

The main reason to include : in an argument is to support
the -P altpath feature of env, another FreeBSD extension.
This is also overdesigned.  If you don't know
where the program is, rely on PATH. If you know where
the program is, put its exact path into the hash bang
script, and don't use the env utility.
The situation "I don't know where the software might be
installed, but it's in one of these
several locations which are not in the PATH" is fairly contrived,
except in one way: when it is known that the software is in
one of the secure, default system locations for programs such
as /bin:/usr/bin, but the PATH could have been altered not
to look in these locations first.

Instead of -P altpath, a single letter option with no argument
can indicate that PATH is to be reset to the secure default,
so that the correct program is found, or else env fails.

Bascially I'm completely against almost every aspect of this
-S design; and I suspect the POSIX standardization people
(Austion Group) won't adopt it, either, so it will forever
remain just a FreeBSD feature (and we can help keep it that
way by not copying it).