]> git.ipfire.org Git - thirdparty/autoconf.git/commitdiff
Disable asynchronous job notification for parallel tests.
authorEric Blake <ebb9@byu.net>
Mon, 13 Jul 2009 18:54:19 +0000 (12:54 -0600)
committerEric Blake <ebb9@byu.net>
Tue, 14 Jul 2009 04:19:15 +0000 (22:19 -0600)
* lib/autotest/general.m4 (AT_INIT) <Driver loop>: Turn off notify
mode, since zsh leaves it on after 'emulate sh'.
* doc/autoconf.texi (Limitations of Builtins) <set>: Document that
job control options are not portable.

Signed-off-by: Eric Blake <ebb9@byu.net>
ChangeLog
doc/autoconf.texi
lib/autotest/general.m4

index 37b7b15c2c61a19387068591bbe8b82fb29dd360..26ddce08be160033e46a4f35c6797e8354dcd374 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2009-07-13  Eric Blake  <ebb9@byu.net>
 
+       Disable asynchronous job notification for parallel tests.
+       * lib/autotest/general.m4 (AT_INIT) <Driver loop>: Turn off notify
+       mode, since zsh leaves it on after 'emulate sh'.
+       * doc/autoconf.texi (Limitations of Builtins) <set>: Document that
+       job control options are not portable.
+
        Guarantee that exit status trumps output matching.
        * doc/autoconf.texi (Writing Testsuites) <AT_CHECK>: Document this
        better.
index a4aed6f8e93f6187b4f65977e6e7556e300a6c95..cd2a65d5b501fbf1a3341f34eab43ca99c7bdae8 100644 (file)
@@ -16257,6 +16257,35 @@ Thus, when writing a script in M4sh, rather than trying to rely on
 @samp{set -e}, it is better to append @samp{|| AS_EXIT} to any
 statement where it is desirable to abort on failure.
 
+@cindex @command{set -b}
+@cindex @command{set -m}
+Job control is not provided by all shells, so the use of @samp{set -m}
+or @samp{set -b} must be done with care.  When using @command{zsh} in
+native mode, asynchronous notification (@samp{set -b}) is enabled by
+default, and using @samp{emulate sh} to switch to Posix mode does not
+clear this setting (although asynchronous notification has no impact
+unless job monitoring is also enabled).  Also, @command{zsh} 4.3.10 and
+earlier have a bug where job control can be manipulated in interactive
+shells, but not in subshells or scripts.  Furthermore, some shells, like
+@command{pdksh}, fail to treat subshells as interactive, even though the
+parent shell was.
+
+@example
+$ @kbd{echo $ZSH_VERSION}
+4.3.10
+$ @kbd{set -m; echo $?}
+0
+$ @kbd{zsh -c 'set -m; echo $?'}
+set: can't change option: -m
+$ @kbd{(set -m); echo $?}
+set: can't change option: -m
+1
+$ @kbd{pdksh -ci 'echo $-; (echo $-)'}
+cim
+c
+@end example
+
+
 @item @command{shift}
 @c ------------------
 @prindex @command{shift}
index b9beb0e65d112eeeb87c461be8744b765432a643..cf88b99cc73fe2a3001fbc3a286d4a3491b625d0 100644 (file)
@@ -1250,7 +1250,8 @@ dnl shell to start each parallel task as its own shell job, thus as a new
 dnl process group leader.  We then send the signal to all new process groups.
 
 dnl Do we have job control?
-if (set -m && set +m) >/dev/null 2>&1; then
+if (set -m && set +m && set +b) >/dev/null 2>&1; then
+  set +b
   at_job_control_on='set -m' at_job_control_off='set +m' at_job_group=-
 else
   at_job_control_on=: at_job_control_off=: at_job_group=