Re: env: add -S option (split string for shebang lines in scripts)

[Pádraig Brady]

On 26/04/18 00:17, Assaf Gordon wrote:
> Hello,
> 
> Attached an updated patch, hopefully addressing all the issues below.
> Initial documentation also included (seperated into several commits to ease 
> review).
> 
> A rendered html page is available here:
>   http://housegordon.org/files//tmp/env-invocation.html
> 
> It's rather long, but I hope it is helpful and justified, to address
> all sorts of subtleties with examples.

Excellent.

> I also added a short blurb to the man page, mentioning the
> "-S" option and directing to the full documentation for details.
> 
> On Tue, Apr 24, 2018 at 10:09:41PM -0700, Pádraig Brady wrote:
>>>> For example it looks buggy that -u TERM
>>>> is just ignored in this example:
>>>>
>>>>   src/env -v -u TERM -S sh -c "echo \$TERM"
> 
> This is fixed now. It requried a minor change to the 'unset' flow,
> which is done in the first commit. Review welcomed.
> 
>> Well according to the FreeBSD docs it should output 'xAAAx ==' in both cases.
>> I'd have a slight preference for being consistent there rather than being
>> bug for bug compat with FreeBSD here.
> 
> The code now behaves in the above consistent way, and thus deviate from
> FreeBSD in this respect.
> 
>>>> Another gotcha is that portably specifying -v
>>>> with -S (i.e. with only one option) requires:
>>>>   src/env '-vS sh -c "echo \$TERM"'
> [...]
>>>> So I would document two forms in the man page/--help like:
>>>>
>>>>   env        [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
>>>>   env -[v]S '[OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]'
> 
> The 'usage' has been updated, and I also added explicit
> section about it in the documentation.
> 
>>>> and make it clear usage() that -S is only needed with shebang lines.
>>>> The quotes above are important to document too,
>>>> as otherwise consistent processing (like interpolation etc.) wouldn't
>>>> be done on operating systems that did split shebangs
>>>> (or when used in a standard command invocation).
> 
> The quotes are tricky: they are needed when running 'env -S' on the command 
> line,
> but should not be used on a shebang line.
> 
> For example, the following results in an infloop (both on FreeBSD and in my 
> implementation):
> 
>     $ cat bad.sh
>     #!/usr/bin/env -S'A=B uname'
> 
> This is because the kernel already passes -S'A=B uname' as a single argument,
> and then env sees the single-quotes. It then sets the envar "A" to the value
> of "B uname". lastly, the kernel adds "./bad.sh" as the last parameter.
> The result is that 'env' sets envvar "A" and runs "bad.sh" again... forever.
> 
> So when using 'env -S' on the command line - use quotes.
> When using 'env -S' in a shebang line - don't use quotes (unless
> when explicitly setting values that contain spaces).
> 
> I have added an explicit section about this in the documentation.

OK all this is very subtle.
Thanks for documenting and matching FreeBSD.
We might consider in future having -S process subsequent parameters
so that scripts would be portable to systems that presplit shebang lines.
Let's not over engineer for now.
Scripts wouldn't be portable when using /usr/bin/env on these systems anyway
as MacOS currently doesn't support -S.

Given -S'with quotes' is only used for debugging
outside the shebang context, and that debugging mode is
adequately documented in the info docs, let's remove the
separate -S mode from the synopsis.  I've done that
and also tweaked the -S explanation a little wrt punctuation.

I also removed exdent from the info as my texinfo version
warns about it, and added static to the two new vars
as indicated by make syntax-check.

All tweaks are attached.

> Lastly, this update does not yet address Kaz's suggestion
> of having a placeholder for the command-line arguments.
> 
> I understand this might be useful in some cases, but I'm
> not sure we want to create yet another GNU extension (compared to FreeBSD).

If we do we should probably do it in a separate patch anyway.

> Are there concrete cases where the interpreter (like awk)
> requires argument in specific order, and the script filename
> can't be last?
> 
> For example in this case:
> 
>     #!/usr/bin/env -S lang -f ${ENV_COMMAND} -x
> 
> Would 'lang' fail to execute if we just reorder it like:
> 
>    #!/usr/bin/env -S lang -x -f

Yes, lang may fail with -x not supported,
or if lang did support -x it would not pass it on to the script.
Though as mentioned previously one can use ${_} to
get awk to behave appropriately.

anyway for future consideration.

thank you!
Pádraig

env-S-tweaks.diff
Description: Text Data