Junio, good day.

Fri, Sep 21, 2007 at 04:52:52PM -0700, Junio C Hamano wrote:
quoted text
> > Option parsing in the Git shell scripts uses the construct 'while
> > case "$#" in 0) break ;; esac; do ... done'.  This is neat, because
> > it needs no external commands invocation.  But in the case when
> > /bin/sh is not GNU Bash (for example, on FreeBSD) this cycle will
> > not be executed at all.
> 
> I do not doubt that "while case $# in 0) break ;; esac" does not
> work for your shell.  But I think the above comment is grossly
> misleading.
> 
> Don't mention bash there.  You sound as if you are blaming
> bashism, but the thing is, your shell is simply broken.

OK, you're right.  Especially if /bin/sh from Solaris and OpenBSD
are working and they are not Bash.  But I would not tell that
the shell is broken now -- I had not seen the POSIX specification.
Does it specifies how the shell should work in this case?

quoted text
> You have other choices than bash on BSD don't you?

Did not understand the question, sorry.  The thing is that
FreeBSD has /bin/sh that is derived from the original Berkeley
shell.  And it is desirable to have it working with Git
script, since I don't want to make bash (or whatever shell
that is not /bin/sh) a dependency for the port.

quoted text
> My quick test shows that ksh, pdksh and dash seem to work
> correctly.  This idiom is what I picked up around late 80's from
> somebody, and kept using on many variants of Unices.  I would
> find quite surprising that something that claims to be a shell
> does not work correctly.  Even /bin/sh that comes with Solaris
> seems to work correctly, which should tell you something.
> 
> OpenBSD's /bin/sh seems to be Ok; I do not know whose shell they
> use, but it seems to be hard-linked to /bin/ksh which is pdksh.

OK, I think I need to find out why FreeBSD's /bin/sh behaves
like this, because the test you propose on your next message
works.  See below.

By the way, my FreeBSD is 7-CURRENT, but I'll test on 6-STABLE
and perhaps on 4-STABLE on Monday.

Fri, Sep 21, 2007 at 07:33:21PM -0700, Junio C Hamano wrote:
quoted text
> I am assuming that this works around _a_ bug in that /bin/sh; I
> would make sure I understand the nature of the bug.  Is it Ok to
> understand that with that shell, after this construct runs:
> 
> 	case <some word> in
>         <case arm #1>)
>         	something ;;
> 	<case arm #2>)
>         	something else ;;
> 	esac
> 
> the status from the whole case statement is false, when <some word>
> does not match any of the glob patterns listed in any of the case arm?
> 
> That is, what does the shell say if you do this?
> 
> 	case Ultra in
>         Super)
>         	false ;;
> 	Hyper)
>         	true ;;
> 	esac &&
>         echo case returned ok

It says 'case returned ok', so I will try to understand why it
works here and does not work in the 'while' construct.

Thanks for the pointer!
-- 
Eygene
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html