On 12/18/14 12:14 PM, Jiri Kukacka wrote:
>> OK, this is the problem part. This looks like a bug in Solaris.
>> There's
>> no indication that the kernel sent SIGHUP before changing the behavior
>> of
>> read and write upon disconnect.
>>
>> Can you see whether or not the first bash in the chain
- chet.ra...@case.edu wrote:
> On 12/18/14, 11:22 AM, Jiri Kukacka wrote:
>
> > 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, 0x0002, 0x000
On 12/18/14, 11:22 AM, Jiri Kukacka wrote:
> 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, 0x0002, 0x, 0x,
> 0x) = 0xFFBFFE
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
somem
On 12/17/14, 4:08 PM, Steve Simmons wrote:
>
> On Dec 17, 2014, at 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 m
On Thu, Dec 18, 2014 at 3:08 PM, Chet Ramey wrote:
>
> 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.
>
I cannot reproduce it in anyway. I flooded the session l
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
> t
On Wed, Dec 17, 2014 at 2:34 PM, Jiri Kukacka wrote:
>
> I investigated the bug, and I found that this happens when machine is too
> slow to send SIGHUP. This also happens when I open a terminal in GUI, and
> close the window (click X). To simulate this, one can just open XTerm
> window, ssh to an
On Wed, Dec 17, 2014 at 9:23 PM, Greg Wooledge wrote:
>
> 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.
that much is certain, that line should not be executed. how much of
this can
On Dec 17, 2014, at 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
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 t
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 be
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 f
13 matches
Mail list logo
