Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Bug in case stmt with '('



> I'm ready to believe that my suggestion doesn't simplify the parser

It would allow removing three lines.

[...]
> What I am suggesting is that the trailing ')' (which if present is UNbalanced)
> not be required to be present.  I.e., each well-formed case-prefix pattern
> (which may have internal parens or '|'s) is terminated by an [external]
> '|', ')', or whitespace; if by whitespace, then the parser considers the
> following token: if it is '|' or ')', then parsing of the case-prefix continues,
> else the case-prefix is considered complete (the parser regards the whitespace
> as equivalent to a trailing ')', if you will), and the token is taken to be
> the initial token of the case-clause body.  Accordingly, I believe that

There is no whitespace token.  Whitespace is a separator and not a token.
Note that

case foo in

f*    |     b*    ) echo yes;;

esac

is a valid case statement.  Autoconf use this kind of case in many places.
Allowing space around | makes the script more readable.  This means that
your new syntax would introduce an ambiguity:

case foo in
f* | echo echo yes;;
esac

The question is wether the first echo is part of the pattern of a command
and | denotes an empty pattern.  Of course you may say that if a pattern
ends in a trailing | it must be followed by a ).  It would really mean that
3 line simplification in the code but it would make the syntax more
complicated.  It think that case works pretty well after my patch and
Bart's latest patch.

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

To fix this would be really difficult I think.

Zoltan



Messages sorted by: Reverse Date, Date, Thread, Author