Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> +The [EMAIL PROTECTED] 4.8 shell
Thanks, but the latest OpenBSD release is 3.9, so there's something
wrong here. Perhaps you meant "3.8"? Or "FreeBSD 4.8"? I've
verified that the bug is in OpenBSD 3.4, so we can assume the bug is
present in more than one OpenBSD release, and the wording should be
suitably vague.
This reminds me of a longstanding related problem in BSD sh and make.
I installed this patch into Autoconf, which combines the two ideas.
2006-05-01 Paul Eggert <[EMAIL PROTECTED]>
and Ralf Wildenhues <[EMAIL PROTECTED]>
* doc/autoconf.texi (Limitations of Builtins, Limitations of Make):
Mention more problems with the -e option.
Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1007
diff -p -u -r1.1007 autoconf.texi
--- doc/autoconf.texi 30 Apr 2006 17:06:13 -0000 1.1007
+++ doc/autoconf.texi 1 May 2006 17:35:37 -0000
@@ -12143,10 +12143,14 @@ Also please see the discussion of the @c
@item @command{set}
@c ----------------
@prindex @command{set}
-This builtin faces the usual problem with arguments starting with a
+With the [EMAIL PROTECTED] 6.0 shell, the @command{set} command (without
+any options) does not sort its output.
+
+The @command{set} builtin faces the usual problem with arguments starting with
a
dash. Modern shells such as Bash or Zsh understand @option{--} to specify
the end of the options (any argument after @option{--} is a parameter,
-even @samp{-x} for instance), but most shells simply stop the option
+even @samp{-x} for instance), but many traditional shells (e.g., Solaris
+10 @command{/bin/sh}) simply stop option
processing as soon as a non-option argument is found. Therefore, use
@samp{dummy} or simply @samp{x} to end the option processing, and use
@command{shift} to pop it out:
@@ -12168,8 +12172,37 @@ better to combine them:
set -ex
@end example
-The @command{set} of the [EMAIL PROTECTED] 6.0 shell does not sort its
-output.
+The @acronym{BSD} shell has had several problems with the @option{-e}
+option, partly because @acronym{BSD} @command{make} traditionally used
[EMAIL PROTECTED] even though this was incompatible with Posix
+(@pxref{Limitations of Make}). Older versions of the @acronym{BSD}
+shell (circa 1990) mishandled @samp{&&}, @samp{||}, @samp{if}, and
[EMAIL PROTECTED] when @option{-e} was in effect, causing the shell to exit
+unexpectedly in some cases. This was particularly a problem with
+makefiles, and led to circumlocutions like @samp{sh -c 'test -f file ||
+touch file'}, where the seemingly-unnecessary @samp{sh -c '@dots{}'}
+wrapper works around the bug.
+
+Even relatively-recent versions of the @acronym{BSD} shell (e.g.,
[EMAIL PROTECTED] 3.4) wrongly exit with @option{-e} if a command within
[EMAIL PROTECTED]&&} fails inside a compound statement. For example:
+
[EMAIL PROTECTED]
+#! /bin/sh
+set -e
+foo='nonempty'
+test -n "$foo" && exit 1
+echo one
+if :; then
+ test -n "$foo" && exit 1
+fi
+echo two
[EMAIL PROTECTED] example
+
[EMAIL PROTECTED]
+does not print @samp{two}. One workaround is to use @samp{if test -n
+"$foo"; then exit 1; fi} rather than @samp{test -n "$foo" && exit 1}.
+Another possibility is to warn @acronym{BSD} users not to use @samp{sh -e}.
@item @command{shift}
@@ -13351,6 +13384,11 @@ remove @file{U} with Posix make, but inc
@command{touch} fails. One way to work around this is to reword the
affected simple-commands so that they always succeed, e.g., @samp{touch
T || :; rm -f U}.
+However, even this approach can run into common bugs in BSD
+implementations of the @option{-e} option of @command{sh} and
[EMAIL PROTECTED] (@pxref{Limitations of Builtins}), so if you are worried
+about porting to buggy BSD shells it may be simpler to migrate
+complicated @command{make} actions into separate scripts.
@item Leading underscore in macro names
Some @command{make}s don't support leading underscores in macro names,
