Date: Tue, 23 Mar 2021 14:51:02 +0300 From: =?UTF-8?B?T8SfdXo=?= <oguzismailuy...@gmail.com> Message-ID: <cah7i3lroxdm_wys7jkqz0qwfvq0bhjgons-ay3q0245tuag...@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