Job control in forced interactive mode upset if stderr is not the controlling tty
I have been playing with a terminal application which runs shells
plumbed as below:
fdwhat
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
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Job control in forced interactive mode upset if stderr is not the controlling tty
I have been playing with a terminal application which runs shells
plumbed as below:
fdwhat
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
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
