Hi,
I found the following shell code in git-tag.sh (and others):
while case "$#" in 0) break ;; esac do ... done
Why not use the straight forward code:
while test "$#" -ne 0 do ... done
Are there any functional difference between them?
Robertoo
Hi,
I found the following shell code in git-tag.sh (and others):
while case "$#" in 0) break ;; esac do ... done
Why not use the straight forward code:
while test "$#" -ne 0 do ... done
Are there any functional difference between them?
Robertoo
Re: uncommon shell code
Robert Watson <robert.oo.watson@gmail.com> writes:
> I found the following shell code in git-tag.sh (and others):
My fault; see point 2. in this article:
http://marc.theaimsgroup.com/?l=git&m=112386506308820&w=2
Please either get used to it or wait until I decide to modernize the scripts wholesale, whichever comes first.
Re: uncommon shell code
On 9/22/05, Junio C Hamano <junkio@cox.net> wrote:
> Robert Watson <robert.oo.watson@gmail.com> writes: > > > I found the following shell code in git-tag.sh (and others): > > My fault; see point 2. in this article: > > http://marc.theaimsgroup.com/?l=git&m=112386506308820&w=2 > > Please either get used to it or wait until I decide to modernize > the scripts wholesale, whichever comes first. >
I see. I thought I was old fashioned by sticking to test instead of [] (that is your point 1), but obviously I am not old enough ;)
Well, it's fine now that I know what it is. But it hurts readability, and probably it's a good idea to simplify it. Any reasonable shell should built-in test(1)?
Robertoo
Re: uncommon shell code
Robert Watson <robert.oo.watson@gmail.com> writes:
> Well, it's fine now that I know what it is. But it hurts > readability, and probably it's a good idea to simplify it.
I try to stay away from style discussion, but readability is always relative and personal. Things like 'while case $# in ..." is an idiom for some but not for others -- and I am included in the former group of people (unfortunately). In any case, 'while test $# != 0' is not too much of a simplification anyway.
> Any reasonable shell should built-in test(1)?
Correct. The idiom comes from performance issues -- lack of built in test long ago -- and that issue is not relevant anymore. But the pattern being an idiom for some still is.
Having said that, I do not feel too strong about enforcing _my_ style. I _do_ feel somewhat strong about consistency, so if somebody wants to update them, without dropping the ball in the middle, it is very likely that I can be persuaded to take a series of patches to modernize them.