Advance apologies if I'm misunderstanding, but the described bug looks like reasonable behavior to me.
When a ssh connection drops, which side notices and when depends on the I/O being done on either side, the state of any keepalive settings, and the timeouts involved. If there's a long time between keepalives and the session is not generating I/O on the server side, I've seen sequences like this: From host A, ssh via wireless to host B. Start command on host B which does not generate network I/O. Abrupt (unplanned) wireless connection lost on host A. In such a case, host B does not yet know the connection has dropped because there is no network activity going on between host A and host B. So it will happily complete the job running on B, then disconnect when the shell on B attempts to send out the next command prompt and it fails. Host A may have noticed the drop well before this, as the user may have attempted type-ahead after the drop or because the ethX interface is lost completely when wireless is lost. Steve On Dec 17, 2014, at 10:54 AM, Chet Ramey <chet.ra...@case.edu> wrote: > On 12/17/14, 8:34 AM, Jiri Kukacka wrote: > >> I understand that this is due to handling EOF from closed TTY as \n, thus >> executing the command, and this is standard behavior of readline, but I >> think the problem is quite serious, so I have to fix it, and I hope that >> you would like this to have fixed as well. >> >> So, my current suggested fix is attached bellow (created for Bash 4.2), >> thanks for any comments to it. > > I would be interested in knowing what happens when the existing code is > executed. In bash-4.2/readline-6.2, rl_getc returns READERR if read(2) > returns -1/errno!=EINTR and readline returns immediately without adding > a newline. It may be that bash executes a command that does not end in > a newline, but in this case it doesn't seem like the code you modified > should be executed. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/ >
