[BUG] Redirect between two parameter assignments causes misbehaviour

[BUG] Redirect between two parameter assignments causes misbehaviour

[dana]

One more before i forget. Someone found this on IRC today and it puzzled us.

The following command produces no output (and returns with 0):

  % a=b 2> /dev/null c=d env

Doesn't matter what the command at the end is, could be a built-in too.

The documentation seems to suggest that it's valid for redirects to be
interspersed amongst the assignments *as well as* the command arguments, so i
think that should work? If not, the documentation needs clarified.

This is generally what happens to the variables afterwards:

  % a=b 2> /dev/null c=d env; print -r -- ${a:--} ${c:--}
  b -

Though it seems that certain interactions with other code can be quite serious.
If i run this without -f, something in my profile causes this series of commands
to hard-lock zsh with 100% CPU. Entering the first command and then the second
one separately avoids this lock-up. Unfortunately `set -x` didn't reveal
anything and i don't have any more time to look at it today, but i thought i'd
mention it.

dana

Re: [BUG] Redirect between two parameter assignments causes misbehaviour

[Daniel Shahaf]

dana wrote on Sun, 10 Dec 2017 18:19 -0600:
> One more before i forget. Someone found this on IRC today and it puzzled us.

Thanks for bringing this to the list.

> Though it seems that certain interactions with other code can be quite serious.
> If i run this without -f, something in my profile causes this series of commands
> to hard-lock zsh with 100% CPU. Entering the first command and then the second
> one separately avoids this lock-up. Unfortunately `set -x` didn't reveal
> anything and i don't have any more time to look at it today, but i thought i'd
> mention it.

It's spinning in the 'while (1)' in gettext2() on WC_END.

If I change the definition of WC_END to 0 then it hits the 'default'
branch of the case, returns from gettext2(), and doesn't spin.

Without having looked any further into it, I wonder whether we should
change WC_END to zero, so if we ever calloc() something and forget to
initialise it, it won't be mistaken for valid data.

Re: [BUG] Redirect between two parameter assignments causes misbehaviour

[Daniel Shahaf]

Daniel Shahaf wrote on Mon, 11 Dec 2017 01:07 +0000:
> It's spinning in the 'while (1)' in gettext2() on WC_END.
> 
> If I change the definition of WC_END to 0 then it hits the 'default'
> branch of the case, returns from gettext2(), and doesn't spin.
> 

Sorry, I meant: change it to a *non-zero* value.

> Without having looked any further into it, I wonder whether we should
> change WC_END to zero, so if we ever calloc() something and forget to
> initialise it, it won't be mistaken for valid data.

Re: [BUG] Redirect between two parameter assignments causes misbehaviour

[Peter Stephenson]

On Sun, 10 Dec 2017 18:19:18 -0600
dana <dana@dana.is> wrote:
> The following command produces no output (and returns with 0):
> 
>   % a=b 2> /dev/null c=d env

This is certainly documented to work.

As redirections at the start work OK I think the fix is as simple as
this.

diff --git a/Src/parse.c b/Src/parse.c
index 5fe3ebd..6af2550 100644
--- a/Src/parse.c
+++ b/Src/parse.c
@@ -1848,6 +1848,10 @@ par_simple(int *cmplx, int nr)
 	    incmdpos = oldcmdpos;
 	    isnull = 0;
 	    assignments = 1;
+	} else if (IS_REDIROP(tok)) {
+	    *cmplx = c = 1;
+	    nr += par_redir(&r, NULL);
+	    continue;
 	} else
 	    break;
 	zshlex();
diff --git a/Test/A04redirect.ztst b/Test/A04redirect.ztst
index cb82751..b8105cf 100644
--- a/Test/A04redirect.ztst
+++ b/Test/A04redirect.ztst
@@ -622,3 +622,10 @@
 >FOO
 >HERE
 >}
+
+  a=b 2>/dev/null c=d
+  print $a
+  print $c
+0:Redirect in the middle of assignments
+>b
+>d

Re: [BUG] Redirect between two parameter assignments causes misbehaviour

[dana]

On 11 Dec 2017, at 06:01, Peter Stephenson <p.stephenson@samsung.com> wrote:
> As redirections at the start work OK I think the fix is as simple as
> this.

That does seem to fix it all of the cases where it previously behaved strangely
for me. No more lock-ups, parameters look as expected afterwards.

dana