----- 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, 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 > > 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 gets a SIGHUP > here? > (Though I can't see why or how sending a SIGHUP to any process other > than > the tty's current foreground process group is useful.)
Well, I can see that SIGHUP got to first bash just a few lines later (and that varies with every test, first this, then the other), and then it was passed through the chain to current foreground process. I can have a look at tty in Solaris, but since other shells don't have this problem, I think that it would be great to have bash aware of such things as well. > > -- > ``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/
