[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#331532: marked as done ([DISCUSS] change �10.4 "set -e OR check return status" to AND or be rewritten)

Your message dated Fri, 06 Jun 2008 13:20:03 -0700
with message-id <873anqqpsc.fsf@windlord.stanford.edu>
and subject line Rejected: Bug#331532: change §10.4 "set -e OR check return status" to AND or be rewritten
has caused the Debian Bug report #331532,
regarding [DISCUSS] change �10.4 "set -e OR check return status" to AND or be rewritten
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

331532: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=331532
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: debian-policy
Severity: minor


the policy says for scripts (§10.4):

Shell scripts (sh and bash) should almost certainly start with set -e so
that errors are detected. Every script should use set -e or check the
exit status of every command. 

This implies that any of these techniques can be used or even worse,
either "set -e" or "check the exit status". 

This leads to serious problems like our X maintainer not checking the
return status in /etc/X11/Xsession and risking the failure of the whole
X startup mechanism just because some irrelevant 3rd party subscript
fails.  This behaviour is justified with §10.4 (everyone has to use set
-e and not return failures).

A quick solution for the misinterpretation of the last words in this
statement could be a change to: 
should use "set -e" and check the exit status of every command.

However, I propose to not force any problem handling technique. "set -e"
has always been a reason for time bombs, problems that are hidden on the
development system since everything works well but cause great problems
in the wild. Especially since such problems are hard to debug because of
not printing any useful output with "set -e". So I propose:

"Every script should should be implemented in the most problem tolerant
way. Exit status of every command should be checked and handled
appropriately if it can cause potential failure."


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-rc2
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

-- no debconf information

--- End Message ---
--- Begin Message ---
This proposal disagrees with the current Policy recommendation that shell
scripts start with set -e or check the exit status of each command.  The
contention in this proposal is that this makes shell scripts unnecessarily
intolerant to problems and scripts should instead continue where possible
after errors.

This is the opposite of the intention of the Policy recommendation, which
is to ensure that all operations in scripts are checked for errors.  The
ignore-by-default error handling in shells is a standard problem with
shell scripting, leading to scripts proceeding dangerously after an error
that should have been fatal.

Debian at this point has significant experience with shell scripts using
set -e, both in maintainer scripts and elsewhere, and this is common
accepted practice.  I don't think there is consensus in this bug report
for a change.  I'm therefore rejecting this proposal.  Due to the lack of
extensive discussion in the original bug report, this is a soft rejection,
meaning that if someone feels strongly about this proposal and wants to
step forward to champion it again, I'd be willing to reopen the bug.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

--- End Message ---

Reply to: