Date: Wed, 9 Jan 2019 12:29:45 +0000
From: Austin Group Bug Tracker <nore...@msnkbrown.net>
Message-ID: <95df9c99cbc201dbbf9de3d53079d...@austingroupbugs.net>
| please reply <b>on the
| mailing list</b> and (if I agree) I will edit this note.
I wish the part of all of this that really belongs in the resolution
of issue 1055 had been left for that one rather than all included
here, and then, one assumes also all included there - as that
issue covers more than aliases, yet has the exact same issues.
That said, I don't disagree with the proposed resolution of any
of that issue in your new wording as it affects aliases, it just
ought all be worded more generally so it applies to everything.
There are just a couple of minor points that I have with your
wording, one where I think a little more clarity is needed, and
one where your wording isn't quite correct.
| ... change to:<blockquote>
| After a TOKEN has been delimited,
This is where I think a little extra clarity would help, and
I'd change that to be
After a token of type TOKEN [xref XCU 2.10.1] has
been delimited,
just to make it clear that TOKEN is a specific type of token,
and not just a weird typographical convention (it helps readers
interpret the meaning more easily).
| If the value of the alias replacing the TOKEN ends in a <blank> that would
| be unquoted after substitution, and optionally if it ends in a <blank> that
| would be quoted after substitution, the shell shall check the next TOKEN in
| the input for alias substitution;
This is where the wording is incorrect, it is not the next TOKEN, which
would imply simply skipping intermediate operators, etc, but the next
token, if and only if, it is a TOKEN, that it is considered for alias
substitution.
There is exactly one chance for this particular alias lookup, blink
and you miss it - the very next token needs to be a valid alias,
otherwise the whole thing stops. Only whitespace that produces
no tokens can intervene (in the original input) between the TOKEN
that was the alias with a value ending with a blank, and the
prospective new alias TOKEN.
Even a comment appearing between ends it, not because of the
comment, which the lexer just drops, but because a comment only
ends when a newline is seen, and that's an operator token, and
so cannot be aliased. (Of course, usually then the next word would
be looked up as an alias anyway, as the word in a command word
position, but that was not because of the trailing blank.)
So I would change
shall check the next TOKEN in the input
into
shall check the next token in the input, if it is a TOKEN,
kre
