[Top][All Lists]

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

Re: Sourcing a file ending in \<newline> disables aliases for 1 command

From: Chet Ramey
Subject: Re: Sourcing a file ending in \<newline> disables aliases for 1 command
Date: Tue, 07 Apr 2015 00:09:16 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 4/3/15 3:55 PM, Eduardo A. Bustamante López wrote:
> I'm replying to this report, because it's the latest.
> This seems to be caused by last_read_token having an incorrect value set.
> `alias_expand_token' in parse.y relies on
> `command_token_position (last_read_token)' (and parser_state), to determine if
> an alias expansion should be performed.
> The correct value of last_read_token there should be of 10:

No, it shouldn't, at least in normal use without setting it specially.
backslash-newline disappears; it's as if it was never read at all:


so last_read_token shouldn't change from WORD.

>   alias_expand_token: last_read_token = 10
> But, for some reason (I don't know if it's parse_and_execute or
> parse_command), after calling `evalstring', this value isn't restored to the
> correct one (shouldn't we care about toplevel's parser status?).

We do, but source is defined to behave as if the lines are taken from the
current input source, so it modifies the parser state and that persists.

Maybe the thing to do is to just push a newline into last_read_token when
_evalfile returns, or call reset_parser().  I'll have to think about the
consequences of doing that and whether it will be noticeably backwards-

> Anyways, I wasn't able to produce a patch for this, because I don't know where
> last_read_token should be reset, or if there's some magic unwind_protect code
> to restore the tokens to the value before calling source/eval, but I hope this
> information makes it easier for Chet to produce a patch.

It does.

> Also, while looking at this, I found this:
> address@hidden ~ % bash -c 'eval \\; echo y'
> y
> address@hidden ~ % bash -ic 'eval \\; echo y'
> exit
> So, that eval is triggering a yacc_EOF, so that triggers the `exit' in the
> interactive shell.

I didn't look closely at this yet, but it seems like the same class of fix
would work.

Thanks for your looking at this.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

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