Re: Bug in case stmt with '('

[Zoltan Hidvegi <hzoli@cs.elte.hu>]

> >Unfortunately there is still an incompatibility in case:
> >
> >case foo in
> >( f* | b* ) echo yes
> >esac
> >
> >should print yes but in zsh it works as
> >
> >case foo in
> >\ f*\ |\ b*\ ) echo yes;;
> >esac
> 
> I was wondering whether that would be the case.  It's a serious problem.
> 
> >To fix this would be really difficult I think.
> 
> It could be easily fixed by modifying glob semantics such that unquoted
> whitespace embedded in a pattern is ignored.  I doubt that any real
> code relies on the current behaviour, which is in any case
> undocumented.

It is used in ${...%...} substitutions where a space stands for itself.
And it is not even a zsh feature.  So unquoted whitespace should not always
be ignored.  Ignoring unquoted whitespace before | and ) and after ( and |
seems to be a better solution but it is more difficult to implement.
Consistency is desirable so patterns should behave similarily in case
statements, ${...%...} substitutions (double quoted or not), in argumenents
to builtins after -m etc.

At a few places the code assumes that the lexer just tokenizes the input
but does not actually modfy it so omitting these spaces in the lexer is not
the best solution.

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 ).  It would require a new
token for a null-space (the word `token' is amiguous in zsh, it can be
either a token returned by gettok or a character token for a character in
ztokens, here I use the second meaning).  A token for null-TAB may also be
necessary here.  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.

On the other topic of empty patterns: it is true that POSIX does not allow
that.  Even previous zsh versions had problems with empty patterns in case
statement so it probably does not cause any problems if we do not allow
that in case statement.  That would simplyfy parsing since it means that
after a BAR a STRING token must come in a case pattern.  But in other
places empty patterns are usefull.  I ofter use (...|) for an optional
match and this should not be disallowed.

Zoltan

PS.  I'm now moving this quite technical discussion to zsh-workers.