Job control in forced interactive mode upset if stderr is not the controlling tty

[Derek Fawcus]

I have been playing with a terminal application which runs shells
plumbed as below:

   fd    what
   0     pty slave
   1     pty slave
   2     some pipe

To get the various shells being used to work,  some of them require
that '-i' be given for force interactive mode,  fair enough.

One problem though,  bash job control is broken by the above.

A job can be started in the background,  and get suspended due to SIGTTIN;
however the job cannot then be resumed.  A simple example being:

bash-3.2$ cat &
[1] 25752
bash-3.2$ jobs
[1]+  Stopped                 cat
bash-3.2$ %
cat
bash: [25751: 1 255] tcsetattr: Invalid argument

[1]+  Stopped                 cat
bash: [25751: 1 255] tcsetattr: Invalid argument
bash-3.2$ 

(I added the '255' debug to help track this down).

I also noticed the versions of ksh and csh that I tested just worked.
This would seem to be because ksh explicitly opened /dev/tty;  and csh
seemed to dup fd 0 (or maybe 1) to use for its interactive input.

Looking at the open fds,  I see that 255 is a dup of 2,  and seems
to be 'shell_tty' from jobs.c;  a simple change to open /dev/tty
fixes this.

@@ -3479,7 +3480,9 @@ initialize_job_control (force)
       /* Get our controlling terminal.  If job_control is set, or
         interactive is set, then this is an interactive shell no
         matter where fd 2 is directed. */
-      shell_tty = dup (fileno (stderr));       /* fd 2 */
+      shell_tty = open("/dev/tty", O_RDWR | O_NONBLOCK);
+      if (shell_tty == -1)
+        shell_tty = dup (fileno (stderr));     /* fd 2 */
 
       shell_tty = move_to_high_fd (shell_tty, 1, -1);
 


So - would there any reason why something like the above should not be applied?

DF