On Tue, Mar 23, 2021 at 8:14 PM Robert Elz <k...@munnari.oz.au> wrote:
> | (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). Apparently I couldn't make myself clear there, sorry. Here's a MRE: alias P1='cat << EOF ' P2A=' foo EOF ' P2B=' ' P3='foo EOF ' # works fine everywhere except bash P1 P2A # doesn't work anywhere P1 P2B P3 I expected both to work. > > | 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). I thought it would keep fetching tokens until reaching one that can't be an alias or is an alias but doesn't have a space at the end, and then go back to the first expanded string and continue from there. > > > 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 > -- Oğuz