* [BUG] Redirect between two parameter assignments causes misbehaviour
@ 2017-12-11 0:19 ` dana
2017-12-11 1:07 ` Daniel Shahaf
2017-12-11 12:01 ` Peter Stephenson
0 siblings, 2 replies; 5+ messages in thread
From: dana @ 2017-12-11 0:19 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG] Redirect between two parameter assignments causes misbehaviour
2017-12-11 0:19 ` [BUG] Redirect between two parameter assignments causes misbehaviour dana
@ 2017-12-11 1:07 ` Daniel Shahaf
2017-12-11 3:20 ` Daniel Shahaf
2017-12-11 12:01 ` Peter Stephenson
1 sibling, 1 reply; 5+ messages in thread
From: Daniel Shahaf @ 2017-12-11 1:07 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG] Redirect between two parameter assignments causes misbehaviour
2017-12-11 1:07 ` Daniel Shahaf
@ 2017-12-11 3:20 ` Daniel Shahaf
0 siblings, 0 replies; 5+ messages in thread
From: Daniel Shahaf @ 2017-12-11 3:20 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG] Redirect between two parameter assignments causes misbehaviour
2017-12-11 0:19 ` [BUG] Redirect between two parameter assignments causes misbehaviour dana
2017-12-11 1:07 ` Daniel Shahaf
@ 2017-12-11 12:01 ` Peter Stephenson
2017-12-11 21:26 ` dana
1 sibling, 1 reply; 5+ messages in thread
From: Peter Stephenson @ 2017-12-11 12:01 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG] Redirect between two parameter assignments causes misbehaviour
2017-12-11 12:01 ` Peter Stephenson
@ 2017-12-11 21:26 ` dana
0 siblings, 0 replies; 5+ messages in thread
From: dana @ 2017-12-11 21:26 UTC (permalink / raw)
To: Peter Stephenson; +Cc: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-12-11 21:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20171211001958epcas4p39fe7f2605374e3ea973e19b62beb9a9c@epcas4p3.samsung.com>
2017-12-11 0:19 ` [BUG] Redirect between two parameter assignments causes misbehaviour dana
2017-12-11 1:07 ` Daniel Shahaf
2017-12-11 3:20 ` Daniel Shahaf
2017-12-11 12:01 ` Peter Stephenson
2017-12-11 21:26 ` dana
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).