Date: Fri, 19 Feb 2021 14:30:25 -0500
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <2b32112c-de72-c713-3f87-6840828c3...@case.edu>
| Nope, it's consistent with the standard.
I can understand that argument.
| that's not a fair reading of rule 4.
Whenever we need to rely upon "fair" readings (which generally means
that it isn't unambiguous, but it "must" mean ...) we have a problem.
It clearly needs to be fixed. bash is alone amongst shells in interpreting
it that way. zsh (while not always very posix conformant) is alone in
interpreting it the way I first suggested. Everyone else allows that "esac"
to be Esac only when it causes a match, and not when it causes a syntax
error, which is what 2.10.1 says.
Of course, this is all more pointless noise in a way, no-one ever uses the
word esac as a case pattern ... if they had some reason to need that, they'd
quote it ("esac" or 'esac' or even just \esac) and remove any possibility of
it being treated as a reserved word.
kre
