bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Redirection between assignment statement and command name prevents alias


From: Oğuz
Subject: Redirection between assignment statement and command name prevents alias substitution
Date: Tue, 23 Mar 2021 20:27:27 +0200

On Tue, Mar 23, 2021 at 8:14 PM Robert Elz <kre@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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]