Date: Mon, 7 Jan 2019 10:10:40 +0000
From: Geoff Clare <[email protected]>
Message-ID: <[email protected]>
| Okay, so along with a fix for the comment issue you and Harald discussed
| recently, here's an updated version of that whole paragraph:
|
| If the value of the alias is not a simple command (see Section 2.9.1)
| minus the terminating control operator,
that part is fine
| or if the value
is a simple
| command minus the terminating control operator but contains a
I think that is over done a little, I'd expect just "or if the value contains"
would be enough.
The "becomes unspecified" cases need not be exclusive, it doesn't
matter if a particular alias is unspecified for 2 or 3 different reasons, it
is still unspecified, so if someone were to do
alias foo='A=3 if >/tmp/bar #'
then this is an unspecified because
it contains an assignment word
it is not a simple command
it contains a redirect
it contains a comment
We do not need to pick one of those (in that case) and make it
unspecified for that exact reason (the way you have it written, it
would be unspecified because it is not a simple command, and
the assignment word, redirect, and comment would all be ignored).
Your words are not wrong, just hard to read (convoluted), where
they do not need to be (in some other contexts hard to read is
necessary, unfortunately, here it is not).
I think I'd replace the long sentence with a ist
If the value of the alias is not a simple command (ref 2.9.1),
without the terminating control operator, or contains any of:
- a variable assignment
- a comment
- any operator (including redirects)
or generates a token which becomes a reserved word,
then the behaviour is unspecified.
To that list we might also add "or if the last two characters of
the value of the alias are an unquoted \ followed by a blank".
The text later makes an unquoted final blank cause alias expansion
of the next word happen .... the only way (as things are to be defined,
rather than as they were) that a quoted final space can happen is with
"\ " as the last two chars (but not "\\ " as the last 3)). I'm not sure,
but I suspect that perhaps not all shells do the same thing with an
alias that ends with "\ ".
Other quoting no longer matters, as none of that can possibly
result in both the final character of the alias being a quoted
space, and the alias value being parsable as a simple command.
(It used to matter, with aliases like
alias foo="echo ' "
but no longer.)
| variable assignment or redirection, the behavior is unspecified.
(that line would go away with the re-write)
| When a word is subject to alias substitution, the value of the alias
| shall be processed to form tokens (see Section 2.3) and the tokens
| shall replace the word,
that is OK I think.
| unless the shell is currently processing an
| alias of the same name,
Here we're still missing what "processing an alias of the same name"
means - the processing steps are not spelled out clearly enough to
make that clear (though I think we all know what it is supposed to mean).
Again, I still think that the right place to put this exclusion is with the
list of conditions that need to apply for alias expansion to be considered,
that is, after:
the word shall be subject to alias substitution if:
which is followed by the bullet list (of items which are "anded", so
all of them must apply).
I'd just add a new item to that list
the word did not result from an earlier alias expansion of the
same word, or of an expansion of any alias, directly or
indirectly, generated from an alias of the same word.
Then we have no "processing an alias" operations to consider, what
matters is where the word came from, not what we happen to be doing
at the time, and the order in which we happen to do it.
| in which case the word shall not be replaced
| in order to prevent infinite loops in recursive aliasing (see below).
The reference to the rationale, nor the explanation (here) is not
really needed - we do not explain why keywords are not looked
up for alias expansion, for example, they just aren't. Same here.
Having something in the rationale about it is fine.
| If a comment would be discarded during token recognition, the behavior
| is unspecified.
As above, I'd keep all the "unspecied if the alias contains" cases
together, rather than having the others earlier, and this one tacked
on the end.
kre
ps: we might want to add a more explicit note in the alias page of XCU 4
that not all strings generate specified behaviour, and to see 2.3.1 for
a list of what is permitted. As it reads now, the ref seems to only be
useful if the reader needs to see the details of how the alias processing
is done, rather than to learn what is permitted (in issue7-TC2
(and earlier) it didn't matter as that was all that was in 2.3.1).
That page might also want to have something added to it to make it
clear that while "alias" is processed as any other command, the alias defined
will not become visible until the shell is parsing future input, data that
has already been parsed will not be affected (so one cannot, for example,
define an alias in a function, and expect that alias to be used in the
same function). And of course, similar (inverted) wording in the unalias
page.
