Re: Bug in case stmt with '('

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Jul 23,  4:01pm, Morris M. Siegel 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?

Given the choice of:

1.  The "current" behavior, i.e. spaces ARE significant only when the
    optional leading paren is there;
2.  The POSIX behavior, i.e. spaces are not significant in case patterns;
3.  Spaces are never significant in glob patterns anywhere.

I'll take (2) before I'll take (3).  My solution is equivalent to (2),
because it makes the spaces insignificant whether or not the opening
paren is there.

The "drawback" of my solution is that it makes PARENTHESES significant
only when the leading paren is there.  I don't have a problem with that
because other shells don't permit parentheses [other than the half-
optional outermost set] at all; thus the optional leading paren is
simply also introducing *additional* optional syntax.

} 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).

I can't find any case where zsh doesn't permit '(' to be a glob metachar.
SH_GLOB relates to parameter and command substitutions, not filenames.
I have no objection to treating the whole case prefix as a single pattern;
as I've said, this is how it already works.

} That's why it's useful to ignore trivial blanks after '(', around '|',
} before ')', and maybe elsewhere, as Zoltan writes.

Except that blanks inside parenthesized glob patterns ARE NEVER TRIVIAL,
by the CURRENT definition of parenthesized glob patters.  I object to
changing this behavior.

} (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)'.  [...])

This is a big reason why I don't like the idea of stripping the spaces
everywhere.  Do YOU really think it user-friendly to have a set of
magic tokens around which spaces are or are not stripped?

} Is there some document containing the formal grammar of zsh?

Only comments in parse.c, unfortunately, and they aren't complete.

} On the contrary, zsh is improved by having glob patterns have
} a uniform meaning throughout the grammar.

I agree with the sentiment, but not with the realization.  IMHO it is
the insignificant spaces in case patterns that should be disallowed,
not spaces in glob patterns that should become insignificant.  POSIX
forbids us from making the better change; I don't believe we should
compound the error by making a worse one.  Two wrongs don't make a
right, and being consistently wrong is not better than being right
whenever possible.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"