odd recursion

odd recursion

[William Scott]

Hi Everyone:

I stumbled onto something that makes me realize there is a lot to zsh I 
don't understand.  I've resolved the problem, but I still don't 
understand it.

The problem comes about if I first define an alias for a command and 
then a posix function for the same command.  Issuing the command after 
doing this results in a recursion and my system freezes up if I am not 
quick with the control-C key.  I am using zsh on OS X v. 10.3.  This 
happens at least with zsh v. 4.1.1 and the current 4.2.3.

Just to be sure, I issue these commands first:

unalias ls
unalias lf
unfunction ls
unfunction lf

alias lf='command ls -Fa'
lf () {
         command ls --color=auto -lh ${*} | egrep "^d"
         command ls --color=auto -lh $* 2>& - | egrep -v "^d|total "
}

Then use lf.

It looks like some sort of recursion happens, even though I don't see 
logically what it is, and I have prefixed ls with "command" in each 
case.

The ONLY cure I found (apart from not doing this) is to use

function lf { commands }



syntax instead of posix syntax.  Then it all works.

The bash to zsh book gave me the impression that the two syntaxes are 
now equivalent.  Clearly that impression is wrong.

Thanks for any insights.

Bill

Re: odd recursion

[Bart Schaefer]

On Jan 31,  8:24am, William Scott wrote:
}
} I stumbled onto something that makes me realize there is a lot to zsh I 
} don't understand.  I've resolved the problem, but I still don't 
} understand it.

You stumbled on FAQ question number 2.3, "Why do my csh aliases not work?
(Plus other alias pitfalls.)"

  There is one other serious problem with aliases: consider

    alias l='/bin/ls -F'
    l() { /bin/ls -la "$@" | more }

  `l' in the function definition is in command position and is expanded
  as an alias, defining `/bin/ls' and `-F' as functions which call
  `/bin/ls', which gets a bit recursive.  This can be avoided if you use
  `function' to define a function, which doesn't expand aliases.  It is
  possible to argue for extra warnings somewhere in this mess.

  Bart Schaefer's rule is:  Define first those aliases you expect to
  use in the body of a function, but define the function first if the
  alias has the same name as the function.

Re: odd recursion

[Thorsten Kampe]

* William Scott (2005-01-31 16:24 +0100)
> I stumbled onto something that makes me realize there is a lot to zsh I 
> don't understand.  I've resolved the problem, but I still don't 
> understand it.
> 
> The problem comes about if I first define an alias for a command and 
> then a posix function for the same command.

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 simultaneously.

Re: odd recursion

[William Scott]

>
> 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 simultaneously.
>
>

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 produced.

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 shell 
initialization.

If the alias is defined after the posix function is defined, the 
problem doesn't arise.

Re: odd recursion

[Seth Kurtzberg]

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 simultaneously.
>>
>>
>
> 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 
> produced.
>
> 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 
> shell initialization.
>
> 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 necessary 
behavior.

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) 
fix that.

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.

>
>
> !DSPAM:41fe79f8244781930316049!
>

Re: odd recursion

[William Scott]

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 
>>> simultaneously.
>>>
>>>
>>
>> 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 
>> produced.
>>
>> 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 
>> shell initialization.
>>
>> 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 
> necessary behavior.
>
> 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) 
> fix that.
>
> 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.
>  

Re: odd recursion

[Bart Schaefer]

On Jan 31,  3:30pm, William Scott wrote:
}
} 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.

There are two bits to this, both of which were touched on in the FAQ
snippet I posted but not really spelled out in detail.

First, the function syntax is not (as you might expect)

	name () { body }

Rather, it's

	name1 name2 name3 ... () { body }

where name2 name3 ... are optional

Thus it's possible to create a whole set of identical functions in a
single pass.  The obscure reason that this is useful is that, when you
setopt FUNCTION_ARGZERO, you can actually have the same function behave
differently depending on its name, just as is sometimes done with C
programs and argv[0].

Second, alias expansion applies to any word in the "command position"
on a command line, BEFORE that command line is parsed.  (Global aliases
are another thing entirely.)  In the expression

	name () { body }

the word "name" is in the command position.  Thus the statements

	alias name='name arguments'
	name () { body }

are equivalent to the single statement

	name arguments () { body }

which, depending on the exact statements in "body", might recursively
reference "name" yet again.