From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.dk (Zsh hackers list)
Subject: Re: order of processing in brace expansion
Date: Wed, 2 May 2001 16:30:10 +0000 [thread overview]
Message-ID: <1010502163010.ZM15909@candle.brasslantern.com> (raw)
In-Reply-To: <Tc0a88d015346c05e98@mailsweeper01.cambridgesiliconradio.com>
On May 2, 4:28pm, Peter Stephenson wrote:
}
} This is rather hairy. The obvious fix is to tokenize braces, too. This
} seems to do the trick, but the change of behaviour is now much more
} obvious. We probably ought to make it either all or nothing. Bash doesn't
} expand braces that result from parameters (probably due to the ordering of
} expansions). Any suggestions?
I'd prefer that the code and the doc agree with on another. Doc:
${~SPEC}
Turn on the GLOB_SUBST option for the evaluation of SPEC; if the
`~' is doubled, turn it off. When this option is set, the string
resulting from the expansion will be interpreted as a pattern
anywhere that is possible, such as in filename expansion and
filename generation and pattern-matching contexts ...
GLOB_SUBST <C> <K> <S>
Treat any characters resulting from parameter expansion as being
eligible for file expansion and filename generation, and any
characters resulting from command substitution as being eligible
for filename generation.
There's no mention of brace expansion there anywhere, and braces are not
expanded in "a pattern" for most senses of "pattern" elsewhere in the doc;
on the other hand, for command substitutions, it's not even supposed to
tokenize a leading `~' or `=', which it obviously does anyway:
zsh% echo $(echo '~')
~
zsh% (setopt glob_subst; echo $(echo '~'))
/home/schaefer
[That latter is definitely a SH_FILE_EXPANSION interaction with GLOB_SUBST;
the GLOB_SUBST doc is describing the case where SH_FILE_EXPANSION is set:
zsh% (setopt glob_subst sh_file_expansion; echo $(echo '~'))
~
So we have some doc to fix even if we don't change comma/brace behavior.]
As of this moment, my leaning in the "all or nothing" category is towards
"nothing", particularly because of the possibility of breaking sh/bash
compatibility (note that GLOB_SUBST is set by default for sh/ksh emulation).
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
next prev parent reply other threads:[~2001-05-02 16:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-27 17:31 Allan Poindexter
2001-04-27 18:09 ` Peter Stephenson
2001-04-28 6:05 ` Bart Schaefer
2001-04-28 18:17 ` Bart Schaefer
2001-05-02 9:50 ` Peter Stephenson
2001-05-02 14:59 ` Bart Schaefer
2001-05-02 15:28 ` Peter Stephenson
2001-05-02 16:30 ` Bart Schaefer [this message]
2001-05-09 9:06 ` Peter Stephenson
2001-05-11 16:57 ` Allan Poindexter
2001-05-11 19:22 ` Allan Poindexter
2001-05-11 20:09 ` 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=1010502163010.ZM15909@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--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).