From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Cc: 255788-forwarded@bugs.debian.org
Subject: Re: Bug#255788: $'' does not work after <<<
Date: Sun, 27 Jun 2004 10:04:45 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.60.0406270942350.19831@toltec.zanshin.com> (raw)
In-Reply-To: <20040627000749.5E7D0865D@pwstephenson.fsnet.co.uk>
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.
next prev parent reply other threads:[~2004-06-27 17:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040623023305.GA15259@localhost>
2004-06-23 17:55 ` Clint Adams
2004-06-23 18:56 ` Bart Schaefer
2004-06-25 9:55 ` Peter Stephenson
2004-06-26 18:34 ` Bart Schaefer
2004-06-27 0:07 ` Peter Stephenson
2004-06-27 17:04 ` Bart Schaefer [this message]
2004-06-27 17:45 ` Peter Stephenson
2004-06-27 18:37 ` Bart Schaefer
2004-06-27 19:44 ` Peter Stephenson
2004-06-28 11:39 ` PATCH: (2): " Peter Stephenson
2004-06-28 15:14 ` Bart Schaefer
2004-06-28 15:29 ` Peter Stephenson
2004-06-28 15:39 ` Peter Stephenson
2004-06-28 17:26 ` Bart Schaefer
2004-06-30 10:00 ` Peter Stephenson
2004-06-30 15:58 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.60.0406270942350.19831@toltec.zanshin.com \
--to=schaefer@brasslantern.com \
--cc=255788-forwarded@bugs.debian.org \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).