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

[Assaf Gordon]

Hello,

Attached an updated patch, hopefully addressing all the issues below.
Initial documentation also included (seperated into several commits to ease 
review).

A renderd 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.

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.

---

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).

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


---

comments very welcomed,
 - assaf

env-S-2018-04-26.patch.gz
Description: application/gzip