Russ Allbery <r...@debian.org> writes:
> martin f krafft <madd...@debian.org> writes:
>
>> I still think set -e is a good idea, but I realise it boils down to
>> preference. If your experience is representative, then it's probably
>> better to advocate not setting set -e in init scripts.
>
>> What about maintainer scripts?
>
> It's almost always correct, in a maintainer script, for the script to
> abort if anything it attempted to do failed. If the maintainer hadn't
> anticipated that failure, having the script continue anyway risks in some
> cases severe data corruption. I think it's therefore much safer to have
> set -e in maintainer scripts and support using it there.
>
> With init scripts, however, since Debian Policy requires that starting a
> daemon that's already running or stopping a daemon that isn't running
> succeed, set -e requires special checking for those cases. If the
> maintainer does that when writing the init script, great, but it seems to
> be a very frequent source of bugs. (I just ran into another case of that
> the other day and need to file a bug about it.)
>
> Init scripts also produce output normally, but if echo fails because
> something is wrong with the console, having the init script silently abort
> is very tricky to debug. I suppose that's also the same with maintainer
> scripts, but it's much less common for maintainer scripts to echo things
> to the console.
Plus set -e gives a false sense of security. As soon as you have
functions in conditionals or compound statements it does no longer work.
E.g.
set -e
start() {
check this
do that
do start the daemon
}
if start; then
SUCCESS
else
FAILED
fi
You would think that the script aborts if anything in start() fails but
no such luck.
Also init scripts should not just abort. What about those nice red
FAILED messages during boot? :)
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
