Date: Wed, 16 Jan 2019 20:02:20 +0000
From: Harald van Dijk <[email protected]>
Message-ID: <[email protected]>
| The exceptions I can find are bash and zsh, which print
| < >
| and pipe that through cat.
The FreeBSD shell as well. This suggests that Geoff's proposed "must not
merge" text in general cannot be supported, as it simply is not what any
shells actually do, there is always merging, just some shells choose to
(sometimes, for bash at least) insert a space between the end of the alias
text and the following characters.
What we might want to say for alias expansion, is something like ...
What we might want to have the standard say, after the part about
recognising the alias in the input, and the part aboutreserved word
tokens being unspecified, but to make clearer what is actually
intended there, change it to ...
except that if the TOKEN meets the above conditions
and would if it occurred in an appropriate place in the
input, be recognized as a reserved word (see [xref to
2.4 Reserved Words]), it is unspecified whether the TOKEN
is subject to alias substitution.
The "is recognised" can be read as only applying when the TOKEN
is in the position where a reserved word is possible, where the
intent of specifying it this way is to deal with the case where an
alias found after a previous alias ends in a space is char for char
equal to a reserved word - but isn't because it is not in the place
where a reserved work can occur.
I'd defer the next (note 4201) paragraph (the one about when changes
to aliases take effect) until lower down, rather then occurring right in
the middle of processing, and then delete the next bullet list, and the
text leading up to it, and following it, entirely, and instead continue
with the "When a TOKEN is subject to alias substitution, ..." paragraph,
except change it to say
When a TOKEN is subject to alias substitution, that TOKEN
is deleted from the input. The value of the alias named by
that TOKEN is inserted into the input stream, ahead of the
character that delimited the alias TOKEN, and lexical
processing resumes with the first character of the alias
value, and continues for the remainder of the value, after
which the previous delimiting character will be observed
again, however perhaps with a different interpretation.
It is unspecified whether a single space character is
inserted between the value of the alias and the characters
that followed the alias TOKEN.
and then continue with the text from note 4201 ...
If the value of the alias replacing the TOKEN ends in a <blank>
(etc).
Then assuming it remains part of this bug interpretation, and isn't
simply moved to 1055 (where it would fit better) the paragraph about
deferring the effective visibility of changes to alias (the effects of the
alias and unalias commands) can be added.
This looks, from the discussions we have been having, as if it will
handle all existing shells, and result in the minimum possible
"unspecified" cases.
In the rationale the effects of the extra (unspecified) added space can
be explained, and perhaps implementations encouraged not to do that.
kre
