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