Harald van Dijk <a...@gigawatt.nl> wrote, on 28 Jan 2019:
>
> >>> If it does not add this <space>, and the last character of
> >>>the alias value could be part of an operator token, it is unspecified
> >>>whether the current token is delimited before token recognition is applied
> >>>to the character (if any) that followed the <b>TOKEN</b> in the input.
> >>
> >>Limiting this to operator tokens will mean, I believe, that in other cases
> >>(unterminated words, heredocs, comments) shells are required to treat the
> >>subsequent characters as part of whatever the alias substitution resulted
> >>in. Is that intentional? Many shells have some corner cases where the end of
> >>an alias substitution delimits a word:
> >>
> >> alias foo='echo $'
> >> foo((123))
> >
> >According to the current wording of note 4214 the foo here is not
> >subject to alias substitution (because of the last condition in the
> >bullet list, "the TOKEN will be parsed as the command name word of a
> >simple command ...")
> >
> >Since foo((123)) is a syntax error as far as the standard grammar is
> >concerned, shells can either report a syntax error or accept the syntax
> >as an extension (with unspecified results).
>
> This could be a re-hash of everyone telling me why that interpretation was
> wrong in the "Alias implementations being invalidated by proposed new
> wording?" thread. This interpretation would mean that
>
> alias foo=#
> foo ()
> {
> echo hello
> }
>
> must print nothing and define a function named foo, since foo is not the
> command name word of a simple command. Pretty much all shells do perform
> alias substitution here (the one exception I know of being mksh), so print
> hello and do not define any function.
>
> What everyone was telling me was that alias recognition happens once a token
> is read. The token just read is foo, and the parser is in a state where foo
> could be interpreted as the command name word of a simple command (without
> looking at the next characters), therefore it is subject to alias
> substitution. This applies to both the examples. If the proposed wording
> does not properly reflect that, that may be a problem in the wording.
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
> >>I think the text can be reduced to
> >>
> >> If it does not add this <space>, it is unspecified whether the current
> >> token is delimited [...]
If the last bullet item is changed along the lines I suggested above,
then I agree with your suggested change here.
> >>This proposed resolution does not leave empty aliases (aliases not resulting
> >>in any token) unspecified.
> >
> >It does if the alias is truly empty. It says that token recognition
> >resumes "at the first character of the alias value". Thus it is silent
> >about the behaviour when there is no first character. However, you're
> >right that it should say something about other no-token values.
>
> Oh, I missed that. Right, there is no benefit in treating
>
> alias foo=""
> and
> alias foo=" "
>
> differently here. The former works in exactly the same shells as the latter,
> as far as I know.
>
> So should this be specified to work, and the shells in which it doesn't
> considered to be buggy?
>
> If so, would it suffice to change
>
> resuming at the first character of the alias value
>
> to
>
> resuming at the start of the alias value
That would be fine with me.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
