Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' - DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' - DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' - DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64 - mtune=generic -O2 -pipe - DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin' -DSTANDARD_UTILS_PATH='/usr/bin:/bin:/usr/sbin:/sbin' - DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' uname output: Linux is010237 2.6.38-ARCH #1 SMP PREEMPT Wed Mar 30 08:47:36 CEST 2011 x86_64 Intel(R) Core(TM)2 Duo CPU P9600 @ 2.53GHz GenuineIntel GNU/Linux Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.2 Patch Level: 8 Release Status: release Description: In a bash script I have to switch on job control using set -m, as it seems to be the only way to trap a SIGCHLD as soon as a background process terminates. The documentation says that 'Background processes run in a separate process group [...]' and this is good. Now it looks like switching on this monitor mode leads also foreground processes to run in a seperate process group. This is a bug, because specification suggests the contrary, and a problem, because the foreground process should receive signals sent to the script's process group. Repeat-By: $ bash -c 'set -m; cat' Observe the process groups of the newly created processes. (Don't try to do this from within the same shell you used to launch the command by pressing ^Z, as this leads to another issue, see below) Fix: I think you should seperate better the concepts of interactive shell and shell with job-control. The latter seems to depend too much on the assumption that the shell is interactive. This also leads to the issue that you can't launch the above command in backgroud. In $ bash -c 'set -m; cat' & only the cat-process is stopped while the bash process continues finding the end of the script and exiting. But maybe all this is just confusing and job control for non interactive shells should be dropped. In this case there should be an option to control whether traps on SIGCHLD should be executed immediately. -- Paolo Herms PhD Student - CEA-LIST Software Safety Lab. / INRIA ProVal Project Paris, France