It was oh so many years ago that I originally wrote that hideously awful
grammar to try to reflect what the ksh did, which was very much ad-hoc
parsing. I won't apologise for the ksh language the grammar tries to
reflect, or for the grammar itself since ksh is definitely not context-free
and thus requires such awfulness. But I feel awful that it's inflicted on
POSIX users.
Which leads me to my recurring plea: there's got to be something better,
and if the POSIX committee were to act to encourage the development of a
shell that was "mostly the same" and for which translation from existing
scripts was straightforward (well... except maybe in ugly cases like this),
it could evolve to something better. I agree with the
existing-implementations policy, but making it clear that the committee was
looking for an improvement (and setting some clear criteria) there would at
least be a hope of something better from some ambitious person. Yes it
would take a long time (a decade or two) for that to reach fruition, but
it's like trees: "What's the best time to plant a tree: 20 years ago.
What's the second best time to plant a tree: now."
Donn
On Fri, Feb 19, 2021 at 7:33 AM Geoff Clare via austin-group-l at The Open
Group <austin-group-l@opengroup.org> wrote:
> Harald van Dijk wrote, on 19 Feb 2021:
> >
> > On 19/02/2021 15:04, Geoff Clare via austin-group-l at The Open Group
> wrote:
> > > Harald van Dijk wrote, on 19 Feb 2021:
> > > >
> > > > On 19/02/2021 09:59, Geoff Clare via austin-group-l at The Open
> Group wrote:
> > > > > How about changing that problem sentence in 2.10.1 to:
> > > > >
> > > > > When a TOKEN is seen where one of those annotated
> productions could
> > > > > be used to reduce the symbol, the applicable rule shall be
> applied to
> > > > > convert the token identifier type of the TOKEN to:
> > > > >
> > > > > * The token identifier of the recognized reserved word, for
> rule 1.
> > > > > * A token identifier acceptable at that point in the
> grammar, for
> > > > > all other rules.
> > > >
> > > > This change would allow
> > > >
> > > > case esac in
> > > > (esac) echo match
> > > > esac
> > > >
> > > > which is currently invalid and rejected by bash, and when invoked in
> POSIX
> > > > mode, also rejected by yash and zsh. Should that become valid, or
> should
> > > > that remain an error?
> > >
> > > It's currently valid and the above change wouldn't affect that (since
> > > the change only affects when rule 1 can be applied, and this example
> > > does not involve rule 1 except for the initial "case").
> >
> > It's currently invalid. The grammar reads:
> >
> > case_item : pattern ')' linebreak DSEMI linebreak
> > | pattern ')' compound_list DSEMI linebreak
> > | '(' pattern ')' linebreak DSEMI linebreak
> > | '(' pattern ')' compound_list DSEMI linebreak
> > ;
> > pattern : WORD /* Apply rule 4 */
> > | pattern '|' WORD /* Do not apply rule 4 */
> >
> > Observe that rule 4 is applied for the first word in a pattern even if
> that
> > pattern follows an opening parenthesis. Because of that, in my example,
> the
> > esac in parentheses is interpreted as the esac keyword token, not a
> regular
> > WORD token that makes for a valid pattern.
>
> Yes, rule 4 is applied there, but your mistake is in assuming that
> the *result* of rule 4 is that the token is converted to an Esac.
>
> > Your change would make it so that since the esac keyword is not
> acceptable
> > at that point in the grammar, it would not be interpreted as the esac
> > keyword, unless I am misreading your change.
>
> You are misreading my change. It does not affect rule 4, only rule 1.
> I.e. the requirement you are arguing against is an existing requirement
> that is not affected by my proposed change.
>
> Also, note that ksh88 accepts that command, and the POSIX description
> is based on ksh88 so this is the intended requirement.
>
> --
> Geoff Clare <g.cl...@opengroup.org>
> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
>
>
