Junio, good day. Fri, Sep 21, 2007 at 04:52:52PM -0700, Junio C Hamano wrote: > > 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? > 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. > 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: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
