Robert Elz <k...@munnari.oz.au> wrote, on 08 Jan 2019: > > | I would prefer that we not leave it unspecified when an alias ends with > "\ ". > | If there is a shell which does recursive alias expansion in this case, we > | should ask the authors/maintainers whether they are willing to change it > | to behave like other shells. > > I don't know of any, but I haven't tested them either ...
Given Chet's reply, it looks like there may be more shells that do expand than don't. In which case I wonder why that "unquoted" text got added in 2016. > | > 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). > | > | I tried to address this by adding the "see below" on the end of this part, > | to make it clear that this is a reference to the value-ends-with-blank > stuff > | described in the next paragraph. > > Ah, no, that's not what it (should be) about at all, if we have > > alias foo='bar ' > > and the input is > > foo foo foo > > then we should generate > > bar bar bar > > An alias that is processed because the previous one ended in a > blank isn't subject to the "currently processing" rule, that cannot > be a problem. > > The aliases that don't get expanded because of this rule are ones > like > > alias ls='ls -l' > > where we really do not want to expand the "ls" that comes from > the value of the alias all over again, even though it is a properly > defined alias, and in the command word position. This surprised me. I was previously unaware that the first word in the alias value is subject to recursive alias expansion. There is nothing in the standard to suggest this happens! (Hence why I thought when it said "recursive" it was referring to the blank-at-the-end thing.) > And similarly, if in the earlier "foo" alias example, we also had > > alias bar=foo > > then the output from "foo foo foo" would be "foo foo foo" > there each "foo" comes from the enpansion of "bar" which > comes from the expansion of "foo" - so indirectly from the > expansion of an alias of the same word. > > > | > 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. > | > | I don't see why this has to be so complicated. > > Perhaps it doesn't - I do tend to write overly complex sentences, as long > as the correct meaning is conveyed, simpler is better. > > | Why is the first part alone not sufficient? > > I would tend to read "result from an earlier alias expansion" > as covering only the words that are in the value of the alias > for the word concerned. So that would cover the "ls" example > above, but not the one with foo and bar both aliases. > > That is, one could (I think reasonably) say that in that foo/bar > case, the word that results from an alias expansion of foo is bar. > bar is not foo, so no problem, look and see if bar is an alias. > Then foo resuilts from an alias expansion of bar, bar is not foo, > so again no problem, look and see if foo is an alias.... So, if > we have only the first part, I am not sure we stop loops. > > | Can you give examples of cases that are covered > | by the "directly or indirectly" part that aren't covered by the > | "earlier alias expansion" part? > > Is the above enough? It is true that the "directly" part is the > same as the first part, but if we said just "indirectly" there, someone > would read it as meaning "not directly" - and I think we need > the extra clarity of the first clause, so just leaving that one out > is probably also not the solution. > > But I have no doubt but that better wording can be found. I think that instead of talking about "direct" and "indirect" it might be better to say that it applies through multiple levels of recursion. > We have not yet generated replacement words for the use of "word", > which as defined, is incorrect for which tokens are looked up to be > aliases, it needs to be TOKEN instead. If this is because IO_NUMBER is not expanded, this change would make no difference to the behaviour required by the standard (because we're saying the behaviour is unspecified if the alias value contains a redirection). > | > ps: we might want to add a more explicit note in the alias page of XCU 4 > > | Do you have a suggested wording change? > > I would maybe simply change "see Section 2.3.1 (on page 2348)." into > something like > > For information on valid string values, and the > processing involved, see Section 2.3.1... > > (and end the previous sentence, ie: s/;/./). Sounds okay. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
