Harald van Dijk <[email protected]> wrote, on 31 Jan 2019:
>
> On 29/01/2019 17:11, Geoff Clare wrote:
> >Okay, it looks like that last bullet item doesn't match existing
> >practice. Instead of:
> >
> > * the TOKEN will be parsed as the command name word of a simple
> > command when the grammatical rules in Section 2.10 are applied
> >
> >how about:
> >
> > * the TOKEN could be parsed as the command name word of a simple
> > command (see [xref to Section 2.10]), regardless of whether any
> > subsequent tokens in the input would allow that
> That looks about right to me, though it might be a bit unclear compared to
> the current wording that in
>
> alias foo=bar
> echo foo
>
> alias substitution should not be performed on "foo". Even though in general
> "foo" could be parsed as the command name word of a simple command, the
> parser state at the time "foo" is seen does not allow it. "will be parsed"
> makes it clear that the current parser state is used, "could be parsed" does
> not achieve that as well. To address that, perhaps it could be expanded to
> something like
>
> * the TOKEN could be parsed as the command name word of a simple
> command (see [xref to Section 2.10]), based on the token and any
> tokens previously read from the input, but ignoring whether any
> subsequent characters would allow that
I agree that's an improvement, but I see one slight problem with it: it
says "tokens previously read from the input" but the previous tokens
could have come from an alias substitution. Here's an attempt to fix
that:
* the TOKEN could be parsed as the command name word of a simple
command (see [xref to Section 2.10]), based on this TOKEN and
the tokens (if any) that preceded it, but ignoring whether any
subsequent characters would allow that
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
