Re: Redirection between assignment statement and command name prevents alias substitution

[Robert Elz]

    Date:        Tue, 23 Mar 2021 14:51:02 +0300
    From:        =?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com>
    Message-ID:  
<CAH7i3LrOxDm_wyS7jKQz0QwFvq0bHjgONS-ay3q0245tuAGpmg@mail.gmail.com>
  | (except aliases that
  | appear in a place where only a here document body may appear, but no shell
  | does that the way I think they'd do, so..)

What do you expect there?   A here doc body comes after a newline after a
here doc redirect operator - it certainly isn't in a command word position,
and because of the newline cannot possibly be immediately after an alias
expansion which requested more alias expansions (the newline would be in
the way).  So, no alias expansion is possible.   Nor would any be wanted
I'd expect, here docs are data not commands (though of course, any data
can become commands if used appropriately ... if that were to happen then
alias expansion would happen to the here doc contents when it is being
parsed as a command string).

  | I don't see the point in checking the syntax of the input in the middle of
  | alias substitution,

In the middle of the substitution, no, but that's not the issue.   Most
shells (I think, but excluding bash for sure) use recursive descent parsers.
Those fetch a token at a time, and sometimes look at the one following.
Each time a token is fetched, the shell indicates whether a reserved word
or alias is possible at this point (and if so, the tokeniser checks, returns
the reserved word token if one is seen, or expands the alias and returns
the first token from the expanded string) - unquoted spaces and tabs, aside
from terminating word tokens, are ignored.  The shell then looks at the token
to decide what should appear next (or if the token cannot occur in the
current situation, generate a syntax error).

In the example in question, the 'l' alias expands to '< ', the token there
is '<' the redirect operator, the space indicates more alias expansion can
follow, but otherwise is discarded.   The "redirect from" token is returned
to the parser, it sees that and starts to parse the redirection, which means
fetching the next token which will be the filename (even though we haven't
seen the command word yet, reserved word lookups must be disabled, and normally
alias expansion would be as well, if it weren't for that space in the 'l'
alias).

So, it isn't so much "checking the syntax" but that the syntax parse is
happening in parallel with fetching tokens, and the two affect each other.

kre