Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Environment variables with nonstandard names are silently dropped on macOS
- X-seq: zsh-workers 41425
- From: Radon Rosborough <radon.neon@xxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Environment variables with nonstandard names are silently dropped on macOS
- Date: Thu, 13 Jul 2017 16:35:47 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=aOI/NKJCRv3iNCW+F4HVZvEJ80FXa+t//+4/OFgPzMA=; b=UbzFdZhbOgxNF8gtS9vGIrzQijO7qwxYqfA+PMbuIEVTGYg/yf6HNuMBHGM4mcGeBg rpbl4CipO3B4BoyE+VEUXIzyVl0qYy2FBt1K0pZy5ac7uftQ8eDgwfGNcqoOD0JCy6RH tX1gwA2DShhGIDobFW04DjtVKHhZNJJ4ZivTo6nvqjCLWdqUgOKM3luTd0NfWmnsoj4N TfRvOsFKnumxjCY22W4mL+SafVkvlIAkqX0+DJLW8gOPf+qKwgQ4WS4E5dtbIDwZW94c JobnISzEBIQTX6fGkgXkaSIcl51p7Wen1BZ4FbwRuo/8VazItV78pmNxNU3r8gPnG1kH rwXg==
- In-reply-to: <CAH+w=7ZaReUDbV5e93bhHUr7imvfsvboF=1RZ9sWjHw-Y8yL6w@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CADB4rJGm=juEDoaNXouUJYnNNsh2ctM2sxa5sMaCfpdem0epfw@mail.gmail.com> <CAH+w=7ZaReUDbV5e93bhHUr7imvfsvboF=1RZ9sWjHw-Y8yL6w@mail.gmail.com>
>
> "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@xxxxxxxxxxxxxxxx>
wrote:
> On Thu, Jul 13, 2017 at 2:07 PM, Radon Rosborough <radon.neon@xxxxxxxxx>
> 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.
>
Messages sorted by:
Reverse Date,
Date,
Thread,
Author