interaction of read(1) and SIGCHLD

[Chris Lightfoot]

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: Linux
Compiler: gcc
Compilation CFLAGS:   -DHAVE_VFPRINTF -DHAVE_UNISTD_H -DHAVE_STDLIB_H 
-DHAVE_LIMITS_H        -DHAVE_GETGROUPS -DHAVE_RESOURCE -DHAVE_SYS_PARAM 
-DVOID_SIGHANDLER -DHAVE_GETDTABLESIZE -DHAVE_BCOPY -DHAVE_GETPW_DECLS 
-DHAVE_GETHOSTNAME -DHAVE_WAIT_H         -DHAVE_DUP2 -DHAVE_STRERROR  
-DHAVE_DIRENT_H -DHAVE_STRING_H        -DHAVE_VARARGS_H -DHAVE_STRCHR  
-DHAVE_DEV_FD        -Di386 -DLinux -DSHELL -DHAVE_ALLOCA -DHAVE_ALLOCA_H       
-O2 -march=i386 -mcpu=i686
uname output: Linux statu.southeast.local 2.2.17 #2 SMP Thu Oct 19 18:28:41 BST 
2000 i686 unknown

Bash Version: 1.14
Patch Level: 7

Description:

read(1) will exit immediately if the shell receives a signal, including
SIGCHLD.

Repeat-By:

Consider a script like

#!/bin/bash
xv fish.jpg &
XVPID=$!
echo type something:
read r
kill -TERM $XVPID

(xv could be replaced with an arbitrary program which runs in the background,
and which the user could terminate in some way.)

If xv quits while the read is waiting for input, read will terminate without
setting the variable r. This is because the call into stdio will fail, with
errno being set to EINTR.

A second bug is that read does not report the failed call into stdio.

Fix:

Re-enable restartable system call semantics when setting signal handlers; the
function set_signal_handler in general.c should do this, but the code to set
the flag is #if'd out. I presume there is some good reason for this
(portability, perhaps) but it ought to work OK on Linux and many other systems.

Bash2 does not have this bug, but I have not compared the signal handling code.