Environment variables with nonstandard names are silently dropped on macOS

Environment variables with nonstandard names are silently dropped on macOS

[Radon Rosborough]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

Hi all,

I recently upgraded from Zsh 5.2 to Zsh 5.3.1, and found that Zsh has
acquired a habit of silently dropping environment variables that have
"nonstandard" names (e.g. they contain periods). The test case to reproduce
is:

    env FOO.BAR=QUUX zsh -c 'printenv FOO.BAR'

In Zsh 5.2 on all operating systems, this prints QUUX. In Zsh 5.3.1 on
macOS (but not elsewhere), it prints nothing and returns nonzero.

The bug was introduced in commit 9dffe404a464289aedade8762795ee4d1bbb1d3f,
which adds a special case for macOS pertaining to environment variable
handling. The patch was designed to fix a more serious bug, namely that
leading equals signs were trimmed in environment variable *values*, but
unfortunately it also introduced this one.

I couldn't find any reference to the issue online, so I thought I would
bring it up here. I don't have the time or skills to contribute a fix,
unfortunately.

Best,
Radon Rosborough

Re: Environment variables with nonstandard names are silently dropped on macOS

[Bart Schaefer]

On Thu, Jul 13, 2017 at 2:07 PM, Radon Rosborough <radon.neon@gmail.com> wrote:
>
>     env FOO.BAR=QUUX zsh -c 'printenv FOO.BAR'
>
> In Zsh 5.2 on all operating systems, this prints QUUX. In Zsh 5.3.1 on
> macOS (but not elsewhere), it prints nothing and returns nonzero.
>
> The bug was introduced in commit 9dffe404a464289aedade8762795ee4d1bbb1d3f,
> which adds a special case for macOS pertaining to environment variable
> handling.

This patch merely changes one #define from config.h, to cause putenv()
to be used in place of setenv() -- there is no other code change.

Unfortunately discarding putenv() as well does not have any effect on
this, because "FOO.BAR" is not a valid identifier in zsh --- you can't
write ${FOO.BAR} without getting "zsh:1: bad substitution" -- and in
fact I don't see how it ever worked with setenv() either, because the
loop that imports the environment skips anything that doesn't match
zsh's definition of an identifier.

Re: Environment variables with nonstandard names are silently dropped on macOS

[Radon Rosborough]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

>
> "FOO.BAR" is not a valid identifier in zsh


That depends on your definition of "valid". Zsh cannot reference such
environment variables directly, but they are still legitimate, in that they
are handled by other applications (and, in fact, are specifically specified
as legitimate by IEEE 1003.1-2001, see [1]).

I don't know anything about setenv() and putenv(), but the fact is that
this worked in 5.2 and doesn't work in 5.3—I found this commit via an
automated 'git bisect run'. You can see the difference yourself, by running
the command I gave. I would argue that it is faulty behavior of Zsh to
discard any environment variables, even if it doesn't provide syntax to
access them directly. In general, shells preserve environment variables
with dots in them: for example, bash, csh, tcsh, ksh, and even fish. The
only one I found that doesn't do this is dash.

[1]: https://stackoverflow.com/a/2821183/3538165

On Thu, Jul 13, 2017 at 4:13 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Thu, Jul 13, 2017 at 2:07 PM, Radon Rosborough <radon.neon@gmail.com>
> wrote:
> >
> >     env FOO.BAR=QUUX zsh -c 'printenv FOO.BAR'
> >
> > In Zsh 5.2 on all operating systems, this prints QUUX. In Zsh 5.3.1 on
> > macOS (but not elsewhere), it prints nothing and returns nonzero.
> >
> > The bug was introduced in commit 9dffe404a464289aedade8762795ee
> 4d1bbb1d3f,
> > which adds a special case for macOS pertaining to environment variable
> > handling.
>
> This patch merely changes one #define from config.h, to cause putenv()
> to be used in place of setenv() -- there is no other code change.
>
> Unfortunately discarding putenv() as well does not have any effect on
> this, because "FOO.BAR" is not a valid identifier in zsh --- you can't
> write ${FOO.BAR} without getting "zsh:1: bad substitution" -- and in
> fact I don't see how it ever worked with setenv() either, because the
> loop that imports the environment skips anything that doesn't match
> zsh's definition of an identifier.
>