I'm sure bash builds on *bsd systems, but none of *bsds ship it by default. Outside of gnu userland (linux, cygwin, mingw?) I don't expect many/any operating systems to ship bash.
I use zsh as interactive shell on freebsd, and on openbsd either install zsh or use ksh which is part of the base system.
git-tools: http://github.com/p/phpbb3/compare/deve ... .git-tools
Git hooks
Re: Git hooks
At least bash is the de-facto standard for linux distros and is also included with Mac OS X. It's less painful to deal with and maintain bash scripts than sh, imo.
But that's just a general statement. These hooks are (at this point) relatively small, so unless they grow I don't see any problem with supporting sh.
But that's just a general statement. These hooks are (at this point) relatively small, so unless they grow I don't see any problem with supporting sh.
Re: Git hooks
In a world where many people equate free operating systems with Linux, I would be quite happy just seeing bashism-removing patches accepted.
With debian and ubuntu moving toward dash as default noninteractive shell there is hope that more scripts would be sh compatible even in linux land.
Also, since we're talking about shells, I would suggest trying zsh. Its completion behavior alone is worth the switch from bash.
With debian and ubuntu moving toward dash as default noninteractive shell there is hope that more scripts would be sh compatible even in linux land.
Also, since we're talking about shells, I would suggest trying zsh. Its completion behavior alone is worth the switch from bash.
Re: Git hooks
I'm all for removing bashisms in simple scripts like this one. Can we not continue to use env though to respect the users path?
Re: Git hooks
Are you talking about using env in shebang line or in the rest of the script?
Re: Git hooks
Well the shebang as you removed it, but both seems appropriate.nn- wrote:Are you talking about using env in shebang line or in the rest of the script?
Re: Git hooks
/bin/sh is the convention when one needs a posix-compliant shell.
The short version: I suggest not messing with it.
The long version: /bin/sh is often built to work on damaged systems. Most shells have an option to statically compile themselves, so that only the actual /bin/sh binary is needed to run shell scripts. Some systems put /usr on its own partition, and if it fails to mount /usr/bin/env would not exist but /bin/sh would still be usable. Using "/usr/bin/env sh" as shebang has the effect of reducing the set of systems capable of running the script.
Now, for phpbb the above is unlikely to be of any practical concern, but I do not recall ever seeing "/usr/bin/env sh" as shebang, ever, so using it would probably raise eyebrows.
In the rest of the script there is no need to use env as binaries will be looked up in PATH by the shell.
The short version: I suggest not messing with it.
The long version: /bin/sh is often built to work on damaged systems. Most shells have an option to statically compile themselves, so that only the actual /bin/sh binary is needed to run shell scripts. Some systems put /usr on its own partition, and if it fails to mount /usr/bin/env would not exist but /bin/sh would still be usable. Using "/usr/bin/env sh" as shebang has the effect of reducing the set of systems capable of running the script.
Now, for phpbb the above is unlikely to be of any practical concern, but I do not recall ever seeing "/usr/bin/env sh" as shebang, ever, so using it would probably raise eyebrows.
In the rest of the script there is no need to use env as binaries will be looked up in PATH by the shell.
Re: Git hooks
We could prepend the branch name with a # to be removed manually.
Re: Git hooks
It's easy to undo/change a commit, I'd rather keep it as it is. At least to me it happens more often that I want to commit than that I do not want to commit and I can add the # myself in those cases.