Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: zsh3.0.0 bug: aliases in if-statement
- X-seq: zsh-workers 2185
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Huy Le <huyle@xxxxxxxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: zsh3.0.0 bug: aliases in if-statement
- Date: Tue, 1 Oct 1996 17:34:20 -0700
- In-reply-to: Huy Le <huyle@xxxxxxxxxxxxxxxxxxxxx> "zsh3.0.0 bug: aliases in if-statement" (Oct 1, 4:51pm)
- References: <199610012351.QAA09318@xxxxxxxxxxxxxxxxxxxxx>
- Reply-to: schaefer@xxxxxxx
On Oct 1, 4:51pm, Huy Le wrote:
> Subject: zsh3.0.0 bug: aliases in if-statement
>
> unalias a b 2>/dev/null
> alias a=cat
> if true; then
> alias b=cat
> works() { echo yes | a }
> fails() { echo yes | b }
> fi
> works2() { echo yes | b }
I've been complaining about this for ages. The problem is that zsh
parses and completely tokenizes the whole "if" statement before it
executes any of it. Thus the textual replacement of "cat" for "b"
in the fails() function, can't happen, because "b" is already a token
rather than a string subject to alias expansion.
Your example is just a more subtle variant of:
fails2() { echo yes | foo }
alias foo=cat
The workaround, of course, is either:
if true; then
alias b=cat
works() { echo yes | a }
eval 'worksToo() { echo yes | b }'
fi
or:
if true; then
alias b=cat
works() { echo yes | a }
worksToo() { echo yes | eval b }
fi
IMHO, alias expansion has always happened too soon in zsh, but it greatly
complicates matters to go around reshaping syntax trees at execution time.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author