Eygene Ryabinkin <rea-git@codelabs.ru> writes:

quoted text
> Good day.
>
> I had found that FreeBSD's /bin/sh refuses to work with git 1.5.3.2.
> correctly: no flags are recognized.  The details and fix are below.
> I don't currently know if the Bash's behaviour is POSIXly correct
> or the 'case' statement semantics is not very well defined.   But
> the following patch fixes the things for the FreeBSD.
>
> Here we go.
>
> -----
>
> 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.

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

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