Fw: "VAR=foo export VAR" no longer works in zsh emulation

Fw: "VAR=foo export VAR" no longer works in zsh emulation

[Peter Stephenson]

Begin forwarded message:

Date: Tue, 24 Jan 2017 13:24:28 +0000
From: Stephane Chazelas <stephane.chazelas@gmail.com>
To: Peter Stephenson <p.stephenson@samsung.com>
Subject: "VAR=foo export VAR" no longer works in zsh emulation


[repost]

looks like my email didn't make it to the zsh-workers ML
yesterday (sent Mon, 23 Jan 2017 15:30:23 +0000), so I'm
reposting it to you. Sorry for the dup if it ever makes its way
to the list.


VAR=foo export VAR

used to work in zsh the same way as in other Bourne-like shells.
That syntax the Bourne equivalent of Korn's:

export VAR=foo

(without the ambiguity of whether VAR=foo should be treated as
an assignment or a command argument).

It no longer works in zsh 5.3.1 ($VAR not modified). As in the
latest Debian unstable package for zsh.

$ VAR=123
$ VAR=abc export VAR
$ echo $VAR
123
$ emulate sh
$ VAR=abc export VAR
$ echo "$VAR"
abc

I found that out when some Bourne-compatible code sourced from
my .zshrc stopped working.

Is the change intentional?

-- 
Stephane

Re: "VAR=foo export VAR" no longer works in zsh emulation

[Peter Stephenson]

On Tue, 24 Jan 2017 13:50:37 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> VAR=foo export VAR
> 
> used to work in zsh the same way as in other Bourne-like shells.
> That syntax the Bourne equivalent of Korn's:
> 
> export VAR=foo
> 
> (without the ambiguity of whether VAR=foo should be treated as
> an assignment or a command argument).

Do you have POSIX_BUILTINS set?  It's needed to get the special
behaviour of not restoring the environment.  I don't think that
behaviour changed recently, though.

% zsh -f
% setopt posixbuiltins
% FOO=bar export FOO
% printenv FOO
bar
%

and

% ARGV0=sh zsh -f
$ FOO=bar export FOO
$ printenv FOO
bar
$

I can believe there could be other weird interactions around, however.

pws

Re: "VAR=foo export VAR" no longer works in zsh emulation

[Bart Schaefer]

On Tue, 24 Jan 2017, Peter Stephenson wrote:

> On Tue, 24 Jan 2017 13:50:37 +0000
> Peter Stephenson <p.stephenson@samsung.com> wrote:
> > VAR=foo export VAR
> >
> > used to work in zsh the same way as in other Bourne-like shells.
>
> Do you have POSIX_BUILTINS set?

Evidently "emulate sh" does not set that and needs to?

Re: "VAR=foo export VAR" no longer works in zsh emulation

[Bart Schaefer]

On Tue, 24 Jan 2017, Bart Schaefer wrote:

> > Do you have POSIX_BUILTINS set?
>
> Evidently "emulate sh" does not set that and needs to?

Sorry, I've got that backwards.  Apparently one did not need to set that
before, and now one does?

Re: "VAR=foo export VAR" no longer works in zsh emulation

[Peter Stephenson]

On Tue, 24 Jan 2017 08:34:43 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Tue, 24 Jan 2017, Peter Stephenson wrote:
> 
> > On Tue, 24 Jan 2017 13:50:37 +0000
> > Peter Stephenson <p.stephenson@samsung.com> wrote:
> > > VAR=foo export VAR
> > >
> > > used to work in zsh the same way as in other Bourne-like shells.
> >
> > Do you have POSIX_BUILTINS set?
> 
> Evidently "emulate sh" does not set that and needs to?

That's the same as the "ARGV0=sh" case, unless I'm somehow doing
something different from what I think I am.

pws

Re: "VAR=foo export VAR" no longer works in zsh emulation

[Peter Stephenson]

On Tue, 24 Jan 2017 08:42:14 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Tue, 24 Jan 2017, Bart Schaefer wrote:
> 
> > > Do you have POSIX_BUILTINS set?
> >
> > Evidently "emulate sh" does not set that and needs to?
> 
> Sorry, I've got that backwards.  Apparently one did not need to set that
> before, and now one does?

It looks up to 5.2 you don't need the option, and this changed in the
commit below.

So it's less sh compatibility, as it still works there, and more
backward compatilibity in zsh.

pws

commit c8de0af35935602370cc79193d0e0d53971250d4
Author: Barton E. Schaefer <schaefer@zsh.org>
Date:   Mon Sep 19 00:25:13 2016 -0700

    39381: handle save/restore of variable values when "typeset"-related reserved words are prefixed by an assignment

diff --git a/ChangeLog b/ChangeLog
index e92c7b2..f9592dd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2016-09-19  Barton E. Schaefer  <schaefer@zsh.org>
+
+	* 39381: Src/exec.c: handle save/restore of variable values when
+	"typeset"-related reserved words are prefixed by an assignment
+
 2016-09-19  Mikael Magnusson  <mikachu@gmail.com>
 
 	* 39351: Functions/Zle/bracketed-paste-url-magic: Handle magnet
diff --git a/Src/exec.c b/Src/exec.c
index 9a7234e..d924148 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -3543,7 +3543,7 @@ execcmd(Estate state, int input, int output, int how, int last1)
 		     * if it's got "command" in front.
 		     * If it's a normal command --- save.
 		     */
-		    if (is_shfunc || (hn->flags & BINF_PSPECIAL))
+		    if (is_shfunc || (hn->flags & (BINF_PSPECIAL|BINF_ASSIGN)))
 			do_save = (orig_cflags & BINF_COMMAND);
 		    else
 			do_save = 1;
@@ -3552,7 +3552,7 @@ execcmd(Estate state, int input, int output, int how, int last1)
 		     * Save if it's got "command" in front or it's
 		     * not a magic-equals assignment.
 		     */
-		    if ((cflags & BINF_COMMAND) || !assign)
+		    if ((cflags & (BINF_COMMAND|BINF_ASSIGN)) || !assign)
 			do_save = 1;
 		}
 		if (do_save && varspc)

Re: "VAR=foo export VAR" no longer works in zsh emulation

[Bart Schaefer]

On Tue, 24 Jan 2017, Peter Stephenson wrote:

> It looks up to 5.2 you don't need the option, and this changed in the
> commit below.
>
> So it's less sh compatibility, as it still works there, and more
> backward compatilibity in zsh.
>
> pws
>
> commit c8de0af35935602370cc79193d0e0d53971250d4
> Author: Barton E. Schaefer <schaefer@zsh.org>
> Date:   Mon Sep 19 00:25:13 2016 -0700
>
>     39381: handle save/restore of variable values when "typeset"-related reserved words are prefixed by an assignment


Hrm, this is a bit ugly.

It might be possible to fix this for "export" by a special-case on the
command name, but it's going to be nearly impossible to make "typeset -x"
behave equivalently, because the save/restore is generic in exec.c where
we barely know what command we're about to run, and we don't learn that
we're exporting until the depths of bin_typeset(), nor propagate that
back out in any way.