zsh-workers
 help / color / mirror / code / Atom feed
* Re: zsh heredoc crash
       [not found]   ` <20160909173515.4cb8392e@pwslap01u.europe.root.pri>
@ 2016-09-10  1:02     ` Bart Schaefer
  2016-09-11 18:02       ` Peter Stephenson
  2016-09-12 23:25       ` Daniel Shahaf
  0 siblings, 2 replies; 5+ messages in thread
From: Bart Schaefer @ 2016-09-10  1:02 UTC (permalink / raw)
  To: zsh-workers

[>workers]

On Sep 9,  5:35pm, Peter Stephenson wrote:
} Subject: Re: zsh heredoc crash
}
} On Fri, 9 Sep 2016 16:33:19 +0200
} Kamil Dudka <kdudka@redhat.com> wrote:
} > On Friday, September 09, 2016 10:00:54 Paulo Cesar Pereira de Andrade wrote:
} > > ---8<---
} > > #!/usr/bin/zsh
} > > 
} > > cat >> /tm/ptry <<EOF
} > > export A="$(tr '\n' ' ' <<BLDARC
} > > content
} > > BLDARC)"
} > > EOF
} > > ---8<---
} > 
} > I was not able to make upstream zsh 5.0.2 crash with the above reproducer.
} 
} That's the underlying bug Paulo is talking about, yes
} (zsh-workers/34322).

I get:

torch% cat >> /tmp/try <<EOF
heredoc> export A="$(tr '\n' ' ' <<BLDARC
heredoc> content
heredoc> BLDARC)"
heredoc> EOF
zsh: parse error

However, if I add another line break, it works:

torch% cat >> /tmp/try <<EOF
export A="$(tr '\n' ' ' <<BLDARC
content
BLDARC  
)" 
EOF
torch% cat /tmp/try
export A="content "
torch% 

This is because gethere() is looking for a *line* containing only the end
token, even though the top of the call chain is parse_event(OUTPAR).  The
desired end token is not passed down through par_sublist().


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: zsh heredoc crash
  2016-09-10  1:02     ` zsh heredoc crash Bart Schaefer
@ 2016-09-11 18:02       ` Peter Stephenson
  2016-09-12  1:13         ` Bart Schaefer
  2016-09-12 23:25       ` Daniel Shahaf
  1 sibling, 1 reply; 5+ messages in thread
From: Peter Stephenson @ 2016-09-11 18:02 UTC (permalink / raw)
  To: zsh-workers

On Fri, 9 Sep 2016 18:02:50 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> I get:
> 
> torch% cat >> /tmp/try <<EOF
> heredoc> export A="$(tr '\n' ' ' <<BLDARC
> heredoc> content
> heredoc> BLDARC)"
> heredoc> EOF
> zsh: parse error

This is a feature:

   <<[-] word
          The shell input is read up to a line that is the same  as  word,
                                          ^^^^
A "line" that matches a "word" means what it says:

% cat <<"HERE)"
heredoc> First line
heredoc> Second line
heredoc> HERE)
First line
Second line

Everything seeems to be working as documented.  ("HERE)" without the
quotes would not be "a word" in the shell sense.)

However, of course, if you think you can make things better without
breaking anything, feel free (I'm certainly not looking for things
to change here).

pws


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: zsh heredoc crash
  2016-09-11 18:02       ` Peter Stephenson
@ 2016-09-12  1:13         ` Bart Schaefer
  0 siblings, 0 replies; 5+ messages in thread
From: Bart Schaefer @ 2016-09-12  1:13 UTC (permalink / raw)
  To: zsh-workers

On Sep 11,  7:02pm, Peter Stephenson wrote:
}
} A "line" that matches a "word" means what it says:

OK.  Bash almost works the same way:

$ echo "$(cat <<EOF
> something
> EOF)"
bash: warning: here-document at line 5 delimited by end-of-file (wanted `EOF')
bash: warning: here-document at line 5 delimited by end-of-file (wanted `EOF')
bash: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
something
EOF)
$ 

So it similarly treats "EOF)" as part of the here-document / not a match
for the end delimiter, but it also closes the quoted string rather than
leave the parser hanging expecting more lines of here-document.

Given our current parsing paradigm I can't think of a way to have zsh
look for "end of here-document or end of current quote whichever comes
first" and the zsh behavior is consistent with the command substitution
having not yet closed either, so I guess we're fine.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: zsh heredoc crash
  2016-09-10  1:02     ` zsh heredoc crash Bart Schaefer
  2016-09-11 18:02       ` Peter Stephenson
@ 2016-09-12 23:25       ` Daniel Shahaf
  2016-09-13  8:29         ` Peter Stephenson
  1 sibling, 1 reply; 5+ messages in thread
From: Daniel Shahaf @ 2016-09-12 23:25 UTC (permalink / raw)
  To: zsh-workers

Bart Schaefer wrote on Fri, Sep 09, 2016 at 18:02:50 -0700:
> This is because gethere() is looking for a *line* containing only the end
> token, even though the top of the call chain is parse_event(OUTPAR).  The
> desired end token is not passed down through par_sublist().

There seems to be a logic error in gethere():

	if (!errflag) {
	    /* Retain any user interrupt error */
	    errflag = ef | (errflag & ERRFLAG_INT);
	}

The assignment is equivalent to «errflag = ef;» due to the if()
condition.  It was added in ab09c24a49951b on the interrupt_abort
branch.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: zsh heredoc crash
  2016-09-12 23:25       ` Daniel Shahaf
@ 2016-09-13  8:29         ` Peter Stephenson
  0 siblings, 0 replies; 5+ messages in thread
From: Peter Stephenson @ 2016-09-13  8:29 UTC (permalink / raw)
  To: zsh-workers

On Mon, 12 Sep 2016 23:25:22 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> There seems to be a logic error in gethere():
> 
> 	if (!errflag) {
> 	    /* Retain any user interrupt error */
> 	    errflag = ef | (errflag & ERRFLAG_INT);
> 	}

I think the intention is the following:

- If there's a (synchronous) error from parsestr(), return that.
- If there isn't, keep the previous error status, but also keep
any (asynchronous) interrupt flag.

pws

diff --git a/Src/exec.c b/Src/exec.c
index 2e251b9..cfd633a 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -4034,7 +4034,7 @@ gethere(char **strp, int typ)
 
 	parsestr(&buf);
 
-	if (!errflag) {
+	if (!(errflag & ERRFLAG_ERROR)) {
 	    /* Retain any user interrupt error */
 	    errflag = ef | (errflag & ERRFLAG_INT);
 	}


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-09-13  8:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAHAq8pEm1FHNvoUJUq2t86P-QKtMdT3uScDUGn-dCscJUGvWew@mail.gmail.com>
     [not found] ` <25855010.qczLe9GZ8n@kdudka-nb>
     [not found]   ` <20160909173515.4cb8392e@pwslap01u.europe.root.pri>
2016-09-10  1:02     ` zsh heredoc crash Bart Schaefer
2016-09-11 18:02       ` Peter Stephenson
2016-09-12  1:13         ` Bart Schaefer
2016-09-12 23:25       ` Daniel Shahaf
2016-09-13  8:29         ` Peter Stephenson

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).