Zsh Mailing List Archive
Messages sorted by:
Re: Bug in case stmt with '('
- X-seq: zsh-workers 1746
- From: segal@xxxxxxxxxx (Morris M. Siegel)
- To: schaefer@xxxxxxx
- Subject: Re: Bug in case stmt with '('
- Date: Tue, 23 Jul 1996 16:01:14 -0400
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx> "Re: Bug in case stmt with '('" (Jul 23, 9:25am)
- References: <199607231408.QAA11293@xxxxxxxxxxxxxxxxx> <960723092557.ZM2043@xxxxxxxxxxxxxxxxxxxxxxx>
On Jul 23, 9:25am, Bart Schaefer wrote:
> Subject: Re: Bug in case stmt with '('
> On Jul 23, 4:08pm, Zoltan Hidvegi wrote:
> } Subject: Re: Bug in case stmt with '('
> } The best would be to handle it in glob.c but here it is a problem how can
> } we distinguish ( foo\ | bar ) from ( foo | bar ).
> The `if (incasepat && ...)' patch that I sent handles this correctly.
> The only drawback I've found so far to my patch is that if you *don't*
> use the POSIX balanced-parens syntax for "case", then parenthesized
> patterns can't have *meaningful* spaces in them.
Do you really think it user-friendly for the semantics of the case-prefix
to depend on whether the optional leading '(' is present or not?
> I don't think this is a significant difficulty, since "case" already
> has the `|' syntax so there's not much reason to use glob-grouping
> parens in "case" patterns in the first place.
It seems to me, and I alluded to this in a previous posting, that it's
most elegant for a whole case-prefix such as
( a | b | c )
to be in fact treated simply as a single zsh glob pattern (again, provided
that zsh options allow '(' to be a glob metacharacter as it usually is).
That's why it's useful to ignore trivial blanks after '(', around '|',
before ')', and maybe elsewhere, as Zoltan writes. (Actually, it might
perhaps be best for all blanks inside parentheses [unless quoted or
backslashed] to be ignored unless their omission would cause distinct
tokens to be erroneously fused. E.g., '( a b | ^ d .c )' would be
equivalent to '(a b|^d .c)'. However, '~' might pose problems, since it
serves both as a directory symbol when unary and as a pattern complementation
operator when binary. At any rate, the need for compatibility with standard
'case' syntax is satisfied if blanks are ignored minimally, as Zoltan
In order for me to participate more intelligently in this discussion,
it would be helpful for me to know where STRINGs occur in the zsh grammar.
Where do they in fact occur besides in glob patterns?
Is there some document containing the formal grammar of zsh?
> } The simplest solution is to convert every unquoted space
> } and TAB which is inside a globbing paren to a null-space and null-tab token
> } and later in glob.c a null-space or null-tab is either treated as space/tab
> } or discarded if it is adjacent to | or comes after a `(' of before a `)'
> } (or it may be better to disard these after `)' and before `(' as well).
> } This seems to be a quite simple solution.
> Maybe, but not simpler than mine, and it's solving a problem that I don't
> think we ought to be solving -- we don't need to be able to ignore spaces
> in generalized glob patterns, only in "case" statements. I don't like the
> suggestion to do it everywhere.
On the contrary, zsh is improved by having glob patterns have
a uniform meaning throughout the grammar.
-- Morrie Siegel
Messages sorted by: