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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.