Configuration Information [Automatically generated, do not change]:
Machine: alpha
OS: OSF1
Compiler: cc -migrate
Compilation CFLAGS:  -DHAVE_SETLINEBUF -DHAVE_VFPRINTF -DHAVE_UNISTD_H -DHAVE_STDLIB_H -DHAVE_LIMITS_H  -DHAVE_GETGROUPS -DHAVE_RESOURCE -DHAVE_SYS_PARAM -DVOID_SIGHANDLER -DNLS -D_BSD -DHAVE_WAIT_H  -DHAVE_GETWD -DHAVE_DUP2 -DHAVE_STRERROR  -DHAVE_DIRENT_H -DHAVE_STRING_H  -DHAVE_VARARGS_H -DHAVE_STRCHR    -Dalpha -DOSF1 -DSHELL  -DHAVE_ALLOCA_H   -O4
uname output: OSF1 pukatea.its.vuw.ac.nz V3.2 148 alpha

Bash Version: 1.14
Patch Level: 5

Description:
        When bash execs another program, the new program inherits an
open file descriptor. File descriptor #5 to be precise. This file
descriptor is open for reading and under various circumstances the new
program will block waiting for input on that descriptor. I have seen
this before on other platforms, but now is is becoming a pain in the
neck, rather than just a bash foible.

Repeat-By:
Take a minimal program e.g.

        main ()
        {
         sleep (3000);
        }

Compile it and run it under gdb. I use GDB 4.14
(alpha-dec-osf3.0). Before the sleep terminates, interrupt the
program. The gdb prompt will appear. Type the quit command. Gdb will
ask you if you are sure because the program is still running. Type 'y'
and then press enter. Gdb now hangs. You can interrupt gdb and it will
terminate.

You can now use ps to look for the process that was being
debugged. You should find that it is blocked waiting for tty
input. e.g.

          PID TTY      S           TIME COMMAND
        19779 ttyp3    T        0:00.11 /u/its/lloyd/tmp/a.out

I have seen similar behaviour from rsh when used the the X11R5/R6
program xon. I have seen this sort of behaviour on NetBSD/i386,
NetBSD/sparc, SunOS 4, and Irix (these are all from memory though).