Re: unfinished command executed when TTY is closed

[Jiri Kukacka]

Hello again,
sorry it took me so long to reply, I got flooded by other work.

This is an example from machines running Solaris 11:
First I open xterm window.
localhost> ssh root@somemachine
somemachine> bash # run this a few times to create tree deep enough
somemachine> bash
somemachine> bash
somemachine> bash
somemachine> bash
somemachine> bash
somemachine> bash
somemachine> bash
somemachine> bash
somemachine> bash
somemachine> touch /tmp/this_shouldnt_be_here #don't send this command
Now I just close xterm window, and when I ssh back to somemachine
somemachine> ls /tmp | grep shouldnt
-rw-r--r--   1 root     root           0 Dec 18 16:05 this_shouldnt_be_here
And here is how /root/.bash_history looks like:
somemachine> tail -12 /root/.bash_history
bash
bash
bash
bash
bash
bash
bash
bash
bash
bash
bash
touch /tmp/this_shouldnt_be_here
I checked what's going on using truss, and here's what is says (just the 
interesting part):
1197:   read(0, " r", 1)                                = 1
1197:   lwp_sigmask(SIG_SETMASK, 0x00000002, 0x00000000, 0x00000000, 
0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
1197:   write(2, " r", 1)                               = 1
1197:   lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 
0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
1197:   read(0, " e", 1)                                = 1
1197:   lwp_sigmask(SIG_SETMASK, 0x00000002, 0x00000000, 0x00000000, 
0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
1197:   write(2, " e", 1)                               = 1
1197:   lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 
0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
1197:   read(0, 0xFFFF80D532B7FE8C, 1)  (sleeping...)
1197:   read(0, 0xFFFF80D532B7FE8C, 1)                  = 0
1197:   write(2, "\n", 1)                               Err#5 EIO
1197:   lwp_sigmask(SIG_SETMASK, 0x00000002, 0x00000000, 0x00000000, 
0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
1197:   ioctl(0, TCSETSW, 0x00537020)                   Err#6 ENXIO
1197:   lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 
0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
1197:   sigaction(SIGINT, 0xFFFF80D532B7FE60, 0xFFFF80D532B7FEC0) = 0
1197:   sigaction(SIGTERM, 0xFFFF80D532B7FE60, 0xFFFF80D532B7FEC0) = 0
1197:   sigaction(SIGQUIT, 0xFFFF80D532B7FE60, 0xFFFF80D532B7FEC0) = 0
1197:   sigaction(SIGALRM, 0xFFFF80D532B7FE60, 0xFFFF80D532B7FEC0) = 0
1197:   sigaction(SIGTSTP, 0xFFFF80D532B7FE60, 0xFFFF80D532B7FEC0) = 0
1197:   sigaction(SIGTTOU, 0xFFFF80D532B7FE60, 0xFFFF80D532B7FEC0) = 0
1197:   sigaction(SIGTTIN, 0xFFFF80D532B7FE60, 0xFFFF80D532B7FEC0) = 0
1197:   sigaction(SIGWINCH, 0xFFFF80D532B7FE60, 0xFFFF80D532B7FEC0) = 0
1197:   sigaction(SIGINT, 0xFFFF80D532B7FE50, 0xFFFF80D532B7FED0) = 0
1197:   brk(0x26CD05000)                                = 0x00000000
1197:   fstatat(AT_FDCWD, ".", 0xFFFF80D532B80D40, 0)   = 0
1197:   fstatat(AT_FDCWD, "/usr/bin/touch", 0xFFFF80D532B80C60, 0) = 0
So you can see that touch command starts to be executed. 1197 is PID of 
bottom-most bash in tree.
I was able to reproduce this in other OS than Solaris, but now I seem to be out 
of luck to do so when I need it to show.
You can also notice that writing "\n" to 2 results in EIO, since stderr is 
dead, as tty get's killed first.
If you need, I can even provide truss log for tty.

----- chet.ramey@case.edu wrote:

> On 12/17/14, 3:23 PM, Greg Wooledge wrote:
> > On Wed, Dec 17, 2014 at 03:16:53PM -0500, Steve Simmons wrote:
> >> Advance apologies if I'm misunderstanding, but the described bug
> looks like reasonable behavior to me.
> > 
> > It would be more reasonable for bash (or ssh, I'm not sure at what
> level
> > this handling should occur) to discard the partially typed line. 
> Not
> > to execute it.
> > 
> > If I open an rxvt and type "touch this_file_should_not_exist" but do
> not
> > press Enter, and then I close the terminal using my window
> manager's
> > "Close" functionality, bash does not execute the partially-typed
> command.
> > (Verified by the absence of the file in a new window.)
> 
> The timing was right: the shell received SIGHUP, it interrupted
> read(2),
> and the shell exited.  This is how it happens in the vast majority of
> cases.
> 
> What the original complaint refers to is what to do in the infrequent
> case when the terminal goes away, the kernel doesn't deliver a
> SIGHUP,
> and a read returns EOF instead of -1.

Well, that's exactly the case that happens to me, and readline changes EOF to 
NEWLINE.

> 
> Chet
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    chet@case.edu   
> http://cnswww.cns.cwru.edu/~chet/

Jiri