Zsh Mailing List Archive
Messages sorted by:
Re: Bug in alias expansion
On Nov 17, 5:29pm, Peter Stephenson wrote:
} We can get rid of the currently visible problems by allocating a new
} string for the token and copying back the result to the original.
A few remarks about this.
(1) This doesn't resolve the problem I pointed out in workers/37123.
(2) Referring to the discussion I've been having with Mikael (cf.
workers/37126), with this patch the alias is expanded in the
parent shell for "alias -g" and in the subshell without -g.
When the $(...) expansion is NOT in subscript context, on the
other hand, the alias expands in the subshell for both global
and command aliases.
(3) I'm fibbing in the last sentence of (2). The alias is expanded
BOTH in the parent shell (which is where the "fooecho" bug from
37123 arises) AND in the subshell. In the parent shell the alias
is expanded during the parse but then (in the case where it lexes
correctly) the expansion is thrown away, only to be re-expanded
in the subshell.
Consequently ... either Mikael is right that the alias expansion
should be forced into the subshell, your patch is thus "wrong," and
my patch in 37122 is closer to what should happen; or the parent is
responsible for the alias, and when we fix 37123 we should make the
behavior outside of subscripts consistent with the behavior inside.
(Of course 37128 and 37122 aren't mutually exclusive, we can apply
both; there's probably some other case where subscript parsing may
go wrong that's fixed by 37128.)
} It's not very efficient, and it still has the problem that if something
} funny happens to the length --- and I don't think there's any guarantee
} of length preservation built into the lexer even though it happens to
} work in the cases we've looked at so far --- then somebody's going to
} get hurt.
I'm not following this stuff about the length -- it can't mean that the
length of the alias expansion is the same as the length of the aliased
token -- so to what does it refer?
Messages sorted by: