In Deb package maintainer script, e.g. postinstall, prerm, etc. I think we often use /bin/sh as shell script interpreter. However, /bin/sh might be different on different distribution or user preferences. For example, Ubuntu link /bin/sh to /bin/dash, or some use might link to /bin/tcsh.
There are two type of syntax I encountered that might failed if user change shell to tcsh.
1) set -e # tcsh can't understand this.
2) > /dev/null 2>&1 # ambiguous redirection.
The first thought is to remove (1), and change (2) to >& /dev/null. However, I found in most maintainer script, the 'set -e' line are presented.
Now, I'm not sure should
a) I just fix all the problem and use /bin/sh b) change to use /bin/bash c) ignore tcsh case
Can anyone provide some suggestions?
Thank you. Jack
The Debian policy doesn't force you to use /bin/sh as shell, you can use any other one provided you name it correctly (with the Shebang) and it is available on the system you try to install to (which limits you to default provided shells if you use it in preinst scripts).
But the Debian policy tells you that /bin/sh, whatever that really is, will always implement the SUSv3 Shell Command Language (i.e.: a shell that is POSIX compliant) and some additional features. That is what you can rely on for your maintainer scripts.
On Debian, /bin/sh was /bin/bash until Lenny. From Squeeze, it is now /bin/dash. See the Debian wiki for more information.
On Debian or any derivatives, if /bin/sh is actually linked to /bin/tcsh it will be a local setting changed by the local administrator. That will probably not only break your scripts but many others. The Debian policy document actually tell maintainers to avoid csh and tcsh as scripting languages.
In conclusion, I think you shouldn't bother about your scripts being compatible with tcsh and the best practice would be to only use /bin/sh for all your packaging needs.
Always refer to the full Debian policy document when in doubt.