Re: Bug#255788: $'' does not work after <<<

Re: Bug#255788: $'' does not work after <<<

[Clint Adams]

Interesting that the x is disappearing.

> Current behaviour (tested with zsh -f):
> 
>    % cat <<< $'x\ny'
>    \ny
> 
> Desired behaviour:
> 
>    % cat <<< $'x\ny'
>    x
>    y
> 
> BASH behaves in the latter manner, the ZSH User Guide shows
> that behaviour, and I see no reason why $'' should not work
> in the context of a here-string.
> 
> Love,
> 
>  -- Miciah <miciah@myrealbox.com>

Re: Bug#255788: $'' does not work after <<<

[Bart Schaefer]

On Wed, 23 Jun 2004, Clint Adams wrote:

> Interesting that the x is disappearing.
> 
> > Current behaviour (tested with zsh -f):
> > 
> >    % cat <<< $'x\ny'
> >    \ny

This may illustrate further:

zsh% x=oops
zsh% cat <<< $'x\ny' 
oops\ny

Re: Bug#255788: $'' does not work after <<<

[Peter Stephenson]

Clint Adams wrote:
> Interesting that the x is disappearing.
> 
> > Current behaviour (tested with zsh -f):
> > 
> >    % cat <<< $'x\ny'
> >    \ny
> > 
> > Desired behaviour:
> > 
> >    % cat <<< $'x\ny'
> >    x
> >    y

I don't know the history of this, but it looks like someone got their
wires crossed, since the remnulargs() in the parsing code is obviously
incompatible with the singsub() in the exec code (er, for certain values
of `obviously').  I haven't dared remove the dupstring() but I suspect
it must be redundant, somehow.

By the way I think this sort of thing ought to work, too:

cat <<$'a\tb'
Here document
a	t

so I've made it.  Again, it does in bash.  That's the first hunk.

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.65
diff -u -r1.65 exec.c
--- Src/exec.c	22 Jun 2004 13:10:02 -0000	1.65
+++ Src/exec.c	25 Jun 2004 09:50:31 -0000
@@ -2714,9 +2714,10 @@
 
     for (s = str; *s; s++)
 	if (INULL(*s)) {
-	    *s = Nularg;
 	    qt = 1;
+	    break;
 	}
+    singsub(&str);
     untokenize(str);
     if (typ == REDIR_HEREDOCDASH) {
 	strip = 1;
Index: Src/parse.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/parse.c,v
retrieving revision 1.45
diff -u -r1.45 parse.c
--- Src/parse.c	22 Jun 2004 13:10:02 -0000	1.45
+++ Src/parse.c	25 Jun 2004 09:50:32 -0000
@@ -1755,7 +1755,7 @@
 	    type = tokstr[0] == Inang ? REDIR_INPIPE : REDIR_OUTPIPE;
 	break;
     case REDIR_HERESTR:
-        remnulargs(name = dupstring(name));
+        name = dupstring(name);
         break;
     }
     yylex();

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Bug#255788: $'' does not work after <<<

[Bart Schaefer]

On Fri, 25 Jun 2004, Peter Stephenson wrote:

> I don't know the history of this, but it looks like someone got their
> wires crossed since the remnulargs() in the parsing code is obviously
> incompatible with the singsub() in the exec code (er, for certain values
> of `obviously').

Um, except that the singsub() wasn't present in the exec code until you
added it just now?  So the remnulargs() was needed to, well, remove the
Nulargs formerly inserted by the loop that you also modified.

Anyway, I think there's still something not quite right here.

Before this patch:

schaefer<501> bar=baz
schaefer<502> cat <<$bar
heredoc> foo
heredoc> baz
heredoc> $bar
foo
baz
schaefer<503>

After this patch:

schaefer<502> cat <<$bar
heredoc> foo
heredoc> baz
foo
schaefer<503> 

Yet here's bash 2.05, which still has the old behavior:

[schaefer]$ bar=baz
[schaefer]$ cat <<$bar
> foo
> baz
> $bar
foo
baz
[schaefer]$ 

> I haven't dared remove the dupstring() but I suspect
> it must be redundant, somehow.

The reason for the dupstring() is that remnulargs() modifies its argument 
in place.  If you take out remnulargs() you can take out the dupstring().

> By the way I think this sort of thing ought to work, too:
> 
> cat <<$'a\tb'
> Here document
> a	t
> 
> so I've made it.

Once this is all working, we'll need to update the tests.

Re: Bug#255788: $'' does not work after <<<

[Peter Stephenson]

Bart Schaefer wrote:
> On Fri, 25 Jun 2004, Peter Stephenson wrote:
> > I don't know the history of this, but it looks like someone got their
> > wires crossed since the remnulargs() in the parsing code is obviously
> > incompatible with the singsub() in the exec code (er, for certain values
> > of `obviously').
> 
> Um, except that the singsub() wasn't present in the exec code until you
> added it just now?  So the remnulargs() was needed to, well, remove the
> Nulargs formerly inserted by the loop that you also modified.

No, the singsub() *was* already in that function (for here strings).
The bit where I added singsub() was in here documents, not here strings.

> Before this patch:
> 
> schaefer<501> bar=baz
> schaefer<502> cat <<$bar
> heredoc> foo
> heredoc> baz
> heredoc> $bar
> foo
> baz
> schaefer<503>
> 
> After this patch:
> 
> schaefer<502> cat <<$bar
> heredoc> foo
> heredoc> baz
> foo
> schaefer<503> 

I guess the print-like behaviour of $'...'  is the only thing we do
want, right?  '...' has no special effect, and "..." does $-style and
`-style expansions which we don't want.  The two approaches seem to be
either an option to untokenize() to remove the bits we don't want
expanded, or dig deeper into singsub() to bring out the bit we want.  (By
the way, I think this compromise sucks, but it does look like we're
stuck with it.)

Hmm, we also need to decide whether this applies to here strings.  My
view would be that they get the full expansion treatment, since they are
essentially a command argument, not a glorified end marker.  But I'm
sure you'll let me know if I'm wrong.  (I'll make this clear in the
documentation either way.)

> > I haven't dared remove the dupstring() but I suspect
> > it must be redundant, somehow.
> 
> The reason for the dupstring() is that remnulargs() modifies its argument 
> in place.  If you take out remnulargs() you can take out the dupstring().

That's what I assumed.  But I didn't really understand how the memory
allocation for the bits of the here-document structures worked.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: Bug#255788: $'' does not work after <<<

[Bart Schaefer]

On Sun, 27 Jun 2004, Peter Stephenson wrote:

> Bart Schaefer wrote:
> > On Fri, 25 Jun 2004, Peter Stephenson wrote:
> > > wires crossed since the remnulargs() in the parsing code is obviously
> > > incompatible with the singsub() in the exec code
> > 
> > Um, except that the singsub() wasn't present in the exec code until you
> > added it just now?
> 
> No, the singsub() *was* already in that function (for here strings).
> The bit where I added singsub() was in here documents, not here strings.

Ah, I see.  Sorry about the, er, crossed wires.

> I guess the print-like behaviour of $'...'  is the only thing we do
> want, right?

That's apparently how bash has implemented it.  Strictly speaking, I think 
zsh had the here-string feature first so we're now modifying the zsh 
feature to match an extension to it that was made by bash, but it seems 
like a reasonable extension.

> '...' has no special effect, and "..." does $-style and
> `-style expansions which we don't want.

Now you're talking about the contents of the here-document, rather than
the value of the end markers?

> The two approaches seem to be either an option to untokenize() to remove 
> the bits we don't want expanded, or dig deeper into singsub() to bring 
> out the bit we want.  (By the way, I think this compromise sucks, but it 
> does look like we're stuck with it.)

I'd vote for the digging in singsub() option, but only if it's possible to
extract the $'...' stuff into a separate function that's callable from 
both places.

> Hmm, we also need to decide whether this applies to here strings.  My 
> view would be that they get the full expansion treatment, since they are 
> essentially a command argument, not a glorified end marker.  But I'm 
> sure you'll let me know if I'm wrong.

I agree with you with one caveat - consider this from bash:

[schaefer]$ string="a word with    spaces in it"
[schaefer]$ cat <<< $string
a word with spaces in it
[schaefer]$ 

I'd have expected "the full expansion treatment" to mean (in bash) that 
the value of $bar was word-split on spaces, producing "<<< a" and "word" 
etc. ... but in the case of a here-string, it gets taken as part of the 
redirection expression, then split, and then pasted back together again 
(which is even odder, from bash).  So I'm not sure exactly what parse bash 
is applying to here-strings.

[schaefer]$ cat < $string
bash: $string: ambiguous redirect
[schaefer]$ 

Hrm.

Re: Bug#255788: $'' does not work after <<<

[Peter Stephenson]

Bart Schaefer wrote:
> > I guess the print-like behaviour of $'...'  is the only thing we do
> > want, right?
> 
> That's apparently how bash has implemented it.  Strictly speaking, I think 
> zsh had the here-string feature first so we're now modifying the zsh 
> feature to match an extension to it that was made by bash, but it seems 
> like a reasonable extension.

But this bit is about here documents, not here strings...

> > '...' has no special effect, and "..." does $-style and
> > `-style expansions which we don't want.
> 
> Now you're talking about the contents of the here-document, rather than
> the value of the end markers?

... and I was talking about the end marker: it seemed to be the
conclusion of what you were saying that in:

cat <<$foo
...
cat <<$'a\tb'
...
cat <<"$(echo hello)"

the \t in the middle case was exanded, but the $ in the other two
weren't.  I haven't even thought about changing anything to do with the
contents.

> > Hmm, we also need to decide whether this applies to here strings.  My 
> > view would be that they get the full expansion treatment, since they are 
> > essentially a command argument, not a glorified end marker.  But I'm 
> > sure you'll let me know if I'm wrong.
> 
> I agree with you with one caveat - consider this from bash:
> 
> [schaefer]$ string="a word with    spaces in it"
> [schaefer]$ cat <<< $string
> a word with spaces in it
> [schaefer]$ 
> 
> I'd have expected "the full expansion treatment" to mean (in bash) that 
> the value of $bar was word-split on spaces, producing "<<< a" and "word" 
> etc. ... but in the case of a here-string, it gets taken as part of the 
> redirection expression, then split, and then pasted back together again 
> (which is even odder, from bash).  So I'm not sure exactly what parse bash 
> is applying to here-strings.

I don't think that's our problem.  We consistently use singsub() for
cases like this and I can't see why we shouldn't here.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: Bug#255788: $'' does not work after <<<

[Bart Schaefer]

On Sun, 27 Jun 2004, Peter Stephenson wrote:

> ... and I was talking about the end marker: it seemed to be the
> conclusion of what you were saying that in:
> 
> cat <<$foo
> ...
> cat <<$'a\tb'
> ...
> cat <<"$(echo hello)"
> 
> the \t in the middle case was exanded, but the $ in the other two
> weren't.

The conclusion seems to be that $'...' is treated as a form of quoting, 
not a form of expansion, whereas `...` is treated as a form of expansion 
rather than a form of quoting; quoting applies, but expansion does not.  
Viz:

[schaefer]$ cat <<`echo foo`
> bar
> foo
> echo foo
> `echo foo`
bar
foo
echo foo
[schaefer]$ 

> I haven't even thought about changing anything to do with the
> contents.

Had my wires crossed again, it seems.

> I don't think that's our problem.  We consistently use singsub() for
> cases like this and I can't see why we shouldn't here.

I'm not sure whether you mean "that's [not] our problem" in the sense of
"that's not what we're doing wrong" or in the sense of "it's not incumbent
upon us to deal with that."

However, if indeed $'...' is meant as a form of quoting, then singsub() 
may be the wrong place for it to be handled -- other forms of quoting are
applied earlier in the parse.

Re: Bug#255788: $'' does not work after <<<

[Peter Stephenson]

Bart Schaefer wrote:
> However, if indeed $'...' is meant as a form of quoting, then singsub() 
> may be the wrong place for it to be handled -- other forms of quoting are
> applied earlier in the parse.

That's an interesting point... you mean there may be other cases where
we've got it wrong.

pws

PATCH: (2): Bug#255788: $'' does not work after <<<

[Peter Stephenson]

OK, it's Monday morning and I spent the entire weekend thinking about
book rewrites and tax returns, so...

Here's a second go, with additions to the test suite.  Since I'm now
very confused, here's an exhausting (sic) list of changes.

Here documents: Nothing changed in the body of the here document.  In
parsing the word after <<, handle all forms of quoting.  ' is unchanged;
" unchanged; ` now does the same thing as double quotes, which means \\
gets turned into \, etc.; backquotes don't do command substitution ---
they never did, but they wouldn't have been stripped properly.  $'...'
now has its standard effect.  (We should probably do that during the
lexical analysis phase, which corresponds to Bart's last point.
However, it seems to be working using the new function quotesubst(), so
I haven't looked at this.)

Here strings: They sort of did expansion before (and this was
documented), but it was a bit botched because the string was massaged to
remove quotes too early.  (The dupstring() has now gone along with the
remnulargs(), for those who care about such things.)  So the test in
A04redirect.ztst with a double-quoted $foo worked but $'...' didn't
work.  This should be more consistent, doing zsh's standard forced
single-word substitution (make sure arrays don't turn it into multiple
words, etc.).  I still don't see any reason why this would be the wrong
thing to do.

Index: Doc/Zsh/redirect.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/redirect.yo,v
retrieving revision 1.6
diff -u -r1.6 redirect.yo
--- Doc/Zsh/redirect.yo	2 May 2003 10:25:32 -0000	1.6
+++ Doc/Zsh/redirect.yo	28 Jun 2004 11:36:26 -0000
@@ -70,12 +70,20 @@
 and `tt(\)' must be used to quote the characters
 `tt(\)', `tt($)', `tt(`)' and the first character of var(word).
 
+Note that var(word) itself does not undergo shell expansion.
+Backquotes in var(word) do not have their usual effect, and
+behave similarly to double quotes.  Quotes in the
+form tt($')var(...)tt(') have their standard effect of expanding
+backslashed references to special characters.
+
 If tt(<<-) is used, then all leading
 tabs are stripped from var(word) and from the document.
 )
 item(tt(<<<) var(word))(
 Perform shell expansion on var(word) and pass the result
 to standard input.  This is known as a em(here-string).
+Compare the use of var(word) in here-documents above, where var(word)
+does not undergo shell expansion.
 )
 xitem(tt(<&) var(number))
 item(tt(>&) var(number))(
Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.65
diff -u -r1.65 exec.c
--- Src/exec.c	22 Jun 2004 13:10:02 -0000	1.65
+++ Src/exec.c	28 Jun 2004 11:36:27 -0000
@@ -2714,9 +2714,10 @@
 
     for (s = str; *s; s++)
 	if (INULL(*s)) {
-	    *s = Nularg;
 	    qt = 1;
+	    break;
 	}
+    quotesubst(str);
     untokenize(str);
     if (typ == REDIR_HEREDOCDASH) {
 	strip = 1;
Index: Src/parse.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/parse.c,v
retrieving revision 1.45
diff -u -r1.45 parse.c
--- Src/parse.c	22 Jun 2004 13:10:02 -0000	1.45
+++ Src/parse.c	28 Jun 2004 11:36:28 -0000
@@ -1754,9 +1754,6 @@
 	if ((tokstr[0] == Inang || tokstr[0] == Outang) && tokstr[1] == Inpar)
 	    type = tokstr[0] == Inang ? REDIR_INPIPE : REDIR_OUTPIPE;
 	break;
-    case REDIR_HERESTR:
-        remnulargs(name = dupstring(name));
-        break;
     }
     yylex();
 
Index: Src/subst.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/subst.c,v
retrieving revision 1.38
diff -u -r1.38 subst.c
--- Src/subst.c	2 Jun 2004 22:14:26 -0000	1.38
+++ Src/subst.c	28 Jun 2004 11:36:29 -0000
@@ -231,6 +231,37 @@
     return errflag ? NULL : node;
 }
 
+/*
+ * Simplified version of the prefork/singsub processing where
+ * we only do substitutions appropriate to quoting.  Currently
+ * this means only the expansions in $'....'.  This is used
+ * for the end tag for here documents.  As we are not doing
+ * `...` expansions, we just use those for quoting and removing
+ * them from the text (they do not get removed by remnulargs()).
+ *
+ * The remnulargs() makes this consistent with the other forms
+ * of substitution, indicating that quotes have been fully
+ * processed.
+ */
+
+/**/
+void
+quotesubst(char *str)
+{
+    char *s = str;
+
+    while (*s) {
+	if (*s == String && s[1] == Snull) {
+	    s = getkeystring(s, NULL, 4, NULL);
+	} else if (*s == Tick || *s == Qtick) {
+	    chuck(s);
+	} else {
+	    s++;
+	}
+    }
+    remnulargs(str);
+}
+
 /**/
 mod_export void
 globlist(LinkList list, int nountok)
Index: Test/A04redirect.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A04redirect.ztst,v
retrieving revision 1.4
diff -u -r1.4 A04redirect.ztst
--- Test/A04redirect.ztst	2 May 2003 10:25:33 -0000	1.4
+++ Test/A04redirect.ztst	28 Jun 2004 11:36:29 -0000
@@ -50,10 +50,34 @@
 0:Here-documents stripping tabs
 >barbar
 
+  cat <<-$'$HERE '`$(THERE) `'$((AND)) '"\EVERYWHERE"
+# tabs again.  sorry about the max miller.
+	Here's a funny thing.  Here is a funny thing.
+	I went home last night.  There's a funny thing.
+	Man walks into a $foo.  Ouch, it's an iron $foo.
+	$HERE $(THERE) $((AND)) \EVERYWHERE
+0:Here-documents don't perform shell expansion on the initial word
+>Here's a funny thing.  Here is a funny thing.
+>I went home last night.  There's a funny thing.
+>Man walks into a $foo.  Ouch, it's an iron $foo.
+
+  cat <<-$'\x45\x4e\x44\t\x44\x4f\x43'
+# tabs again
+	This message is unfathomable.
+	END	DOC
+0:Here-documents do perform $'...' expansion on the initial word
+>This message is unfathomable.
+
   cat <<<"This is a line with a $foo in it"
 0:'<<<' redirection
 >This is a line with a bar in it
 
+  cat <<<$'a\nb\nc'
+0:here-strings with $'...' quoting
+>a
+>b
+>c
+
   exec 3>redir  &&  print hello >&3  &&  print goodbye >&3  && cat redir
 0:'>&' redirection
 >hello

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: PATCH: (2): Bug#255788: $'' does not work after <<<

[Bart Schaefer]

On Mon, 28 Jun 2004, Peter Stephenson wrote:

> " unchanged; ` now does the same thing as double quotes, which means \\
> gets turned into \, etc.; backquotes don't do command substitution ---
> they never did, but they wouldn't have been stripped properly.

Er, stripped?  They shouldn't get stripped, at least not when used as the 
marker for a here-doc.  My example from previous mail showed that:

[schaefer]$ cat <<`echo foo`
> bar
> foo
> echo foo
> `echo foo`
bar
foo
echo foo
[schaefer]$ 

(We could argue that bash is wrong in this case, but ...)

(I admit I haven't tried this second patch yet, so sorry if I've jumped to
the wrong conclusion here.)

> Here strings: [...] This should be more consistent, doing zsh's standard 
> forced single-word substitution (make sure arrays don't turn it into 
> multiple words, etc.).  I still don't see any reason why this would be 
> the wrong thing to do.

This is fine as long as it doesn't change the behavior of here-documents.
Sorry if I inadvertently implied otherwise at any point.

Re: PATCH: (2): Bug#255788: $'' does not work after <<<

[Peter Stephenson]

Bart Schaefer wrote:
> On Mon, 28 Jun 2004, Peter Stephenson wrote:
> 
> > " unchanged; ` now does the same thing as double quotes, which means \\
> > gets turned into \, etc.; backquotes don't do command substitution ---
> > they never did, but they wouldn't have been stripped properly.
> 
> Er, stripped?  They shouldn't get stripped, at least not when used as the 
> marker for a here-doc.  My example from previous mail showed that:

Grud.  I can easily fix this.  I will then commit it without asking, in
case there are yet more problems...  By the way, Solaris zsh treats
backquotes in the normal fashion, though doesn't do $-expansion.
However, ksh 88 is like bash.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: PATCH: (2): Bug#255788: $'' does not work after <<<

[Peter Stephenson]

Peter Stephenson wrote:
> Grud.  I can easily fix this.  I will then commit it without asking, in
> case there are yet more problems...  By the way, Solaris zsh treats
> backquotes in the normal fashion, though doesn't do $-expansion.
> However, ksh 88 is like bash.

I meant Solaris sh, of course.

Now committed with the change indicated by Bart.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: PATCH: (2): Bug#255788: $'' does not work after <<<

[Bart Schaefer]

On Mon, 28 Jun 2004, Peter Stephenson wrote:

> Grud.  I can easily fix this.  I will then commit it without asking, in
> case there are yet more problems...

Well, only kinda.  See what happens with unbalanced backticks:

schaefer<501> cat <<`echo `foo `bar
bquote> `
bquote> `
bquote> `
bquote> 

The only way to get out of this is to interrupt the shell.

However, bash appears to have exactly this same problem, though it's 
harder to tell where the parser is stuck because bash lacks the %_ 
expando.

Re: PATCH: (2): Bug#255788: $'' does not work after <<<

[Peter Stephenson]

I've finally plucked up my courage for another round...

Bart Schaefer wrote:
> On Mon, 28 Jun 2004, Peter Stephenson wrote:
> 
> > Grud.  I can easily fix this.  I will then commit it without asking, in
> > case there are yet more problems...
> 
> Well, only kinda.  See what happens with unbalanced backticks:
> 
> schaefer<501> cat <<`echo `foo `bar
> bquote> `
> bquote> `
> bquote> `
> bquote> 
> 
> The only way to get out of this is to interrupt the shell.

Hmmm... are you sure?  After the patch I get

% cat <<`echo `foo `bar
bquote> `
heredoc> 

which is what I expect.

At this point, there's no way of finishing the here-document because it
parses line by line and can't match the newline.  This is common to all
forms of quoting.  But that's not what was worrying you, by the looks of
it.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: PATCH: (2): Bug#255788: $'' does not work after <<<

[Bart Schaefer]

[I've dropped bugs.debian.org from this.]

On Wed, 30 Jun 2004, Peter Stephenson wrote:

> I've finally plucked up my courage for another round...
> 
> Bart Schaefer wrote:
> > 
> > schaefer<501> cat <<`echo `foo `bar
> > bquote> `
> > bquote> `
> > bquote> `
> > bquote> 
> 
> Hmmm... are you sure?

Ah, it's SUN_KEYBOARD_HACK causing the solitary backtick to be silently
discaraded.  With "zsh -f" I get what you got:

> % cat <<`echo `foo `bar
> bquote> `
> heredoc> 
> 
> At this point, there's no way of finishing the here-document because it
> parses line by line and can't match the newline.

I see; but if completion is active you're now in a state where it's not 
possible to get zsh to recognize the EOF character, unless it's bound to 
something different than delete-char-or-list.  So you must type interrupt 
to get on with your life.  That's what bothers me ... but I guess it was 
always that way and I just never noticed before.