Date: Sun, 21 Feb 2021 18:11:23 +0100
From: "Joerg Schilling via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <20210221171123._9r9e%sch...@schily.net>
| It would be interesting to know whether shells that accept
|
| case easac in
|
| esac) echo yes
| ;;
| esac
Which shells are those? As far as I can tell, all shells interpret
that as intended (the "esac" in what looks like the pattern is Esac).
So
| also accept the same without ;;
this is a meaningless question.
| BTW: are there shells that support the statement without '('?
No. This was clear ages ago.
The shells that accept this with the '(' don't care whether the final ;;
is present or not, nor can I imagine why that would make a difference, the
command list has to be parsed first, and by the time that's done, whether
a pattern looked like "esac" is long forgotten (that is, buried into the
case statement data structures).
There are 2 issues.
"case esac in esac" (really, "case anything in esac")
and
"case anything in (esac) /*whatever */ esac".
Making the POSIX grammar correctly allow the first, while not at the
same time permitting "do something" as a command, and then sorting out
what should be done with the second, where all shells don't do the same
are what is being discussed.
kre
ps:
| This is to permit the last case to end without ;; before the esac.
I would dispute the causality there (not that it matters any more), I'd
say it is more that the way the test was written allowed the last case
to skip ;; before esac, rather than being deliberately written that way
with that goal in mind. Being able to omit the ";;" isn't a feature (it
has no practical benefit), it's just a quirk.
Given that, when support for the '(' was added, it seems more likely to
me that it was simply a programming decision how to insert it, rather that
any particular attempt to permit (unquoted) esac as a pattern. It just
happened to have that effect (which perhaps wasn't noticed when the posix
grammar was written).
