From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7343 invoked by alias); 13 Jul 2017 23:36:31 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41425 Received: (qmail 29074 invoked from network); 13 Jul 2017 23:36:31 -0000 X-Qmail-Scanner-Diagnostics: from mail-it0-f48.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.214.48):SA:0(0.5/5.0):. Processed in 1.181842 secs); 13 Jul 2017 23:36:31 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_SPAM, SPF_PASS,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: radon.neon@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.214.48 as permitted sender) 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== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=aOI/NKJCRv3iNCW+F4HVZvEJ80FXa+t//+4/OFgPzMA=; b=J059W6eajAMXDplDJWFdva5CPuxWO5tHc7juItLWl+w8gjLrQHCoaTAUmWLFRJ+kT0 B60de/SB7ntNcJ14/e3DgFLjK2dWf+cc8rMacER8oLek8RDrb/ck3ewf0ekcvk9x2dlu RIV8J8L+0AYxki76Qx408ljHMxV+nkieLrmTViiz1jPjSU5x8Iairt5K4me7O5yi5UNx s58kE4oYgpgYVWOYGIhQeuGkQE0mNl1ZjRzndzAFQIU+dV8jvhFKClvX0aI/cGcmi1cl YKMRu6U/hFpRfGDg+PZ5eJ2V36KcVdxQ33SpQ/sk1rvRyc4ThzaTSY9UyiEULemOpoei 4Bbw== X-Gm-Message-State: AIVw110B8OZp/HZr7Biv1GQ0OM5gumqEgPoXBnh13eKhfp31/v+ANOhJ dd1+H9ShWJpYgYI0z3lqqBcUk6TsP+tSABk= X-Received: by 10.36.71.79 with SMTP id t76mr1386235itb.118.1499988987584; Thu, 13 Jul 2017 16:36:27 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Radon Rosborough Date: Thu, 13 Jul 2017 16:35:47 -0700 Message-ID: Subject: Re: Environment variables with nonstandard names are silently dropped on macOS To: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="001a113f8904c5aa4d05543b66c4" --001a113f8904c5aa4d05543b66c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > "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=E2=80=94I 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 wrote: > On Thu, Jul 13, 2017 at 2:07 PM, Radon Rosborough > wrote: > > > > env FOO.BAR=3DQUUX 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. > --001a113f8904c5aa4d05543b66c4--