Zsh Mailing List Archive
Messages sorted by:
Re: odd recursion
- X-seq: zsh-users 8446
- From: William Scott <wgscott@xxxxxxxxxxxxxxxxxx>
- To: L:ZSH-users <zsh-users@xxxxxxxxxx>
- Subject: Re: odd recursion
- Date: Mon, 31 Jan 2005 15:30:34 -0800
- In-reply-to: <41FE98A3.8040700@xxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <5ced8dfb84fe26e20350095da48dd44d@xxxxxxxxxxxxxxxxxx> <1ba5918552xff.dlg@xxxxxxxxxxxxxxxx> <6f5f1b5c88ce1d0196392e62bcf981f1@xxxxxxxxxxxxxxxxxx> <41FE98A3.8040700@xxxxxxx>
Thanks very much to everyone who answered.
Just to clarify -- I know the simplest solution is just to avoid it,
the next most simple solution is to use
zsh/ksh function syntax rather than posix syntax.
The main point of the question was that I don't see how/why it is a
recursion, from the logic of the expressions, which is why I said there
was some sort of fundamental gap in my understanding of how zsh works.
On Jan 31, 2005, at 12:44 PM, Seth Kurtzberg wrote:
William Scott wrote:
I hope you have your reasons to tell the shell "a is b" and "a is c"
at the same time. Basically your aliasing ls two times
The interesting thing is that if I issue
"which lf" it tells me that lf is aliased, not that it is defined as
a function. If I then issue the newly defined lf command, the
function takes precedence over the alias (which is what I understood
to be the expected behavior), which I can see from the error messages
The problem arose because a user made the alias without checking to
see that the function was defined, and that the function was written
as a posix function and defined after the alias in the sequence of
If the alias is defined after the posix function is defined, the
problem doesn't arise.
I don't see any way around this, without taking away good and
You can always use the really simple solution, which is not to have a
name clash at all. I use a short script I wrote to tell me whether a
name is already defined somewhere. It's got a bug in it w.r.t.
functions (which makes it useless at the moment) but I'll (presumably)
IMHO, it is always better to keep things explicit rather than relying
on the sequence of operations in the implementation.
A warning, as someone suggested, might be a better solution.
Messages sorted by: