Re: problem suspending "man bash" (intermittent)

[Lev Bishop <lev dot bishop at yale dot edu>]

SO I have been poking around some more and I can report some more details.
I can say that it doesn't seem to be a problem with man, bash or less, and
rather seems to be a problem concerning the way cygwin sends signals to a
pipeline. The reason it showed up with "man bash" rather than others is
simply that the bash manpage is quite long, meaning that less doesn't suck
up all of cat's output immediately - if I page to the bottom of the
manpage then less gets all the data, cat terminates and these problems go
away. If you can't replicate my issues maybe check that all the processes
in the pipeline are still running and if necessary pipe a longer file to
less.

Reading the archives again, I see this message from Oct 2002:
http://www.cygwin.com/ml/cygwin/2002-10/msg00513.html
where Christopher Faylor says he's fixed a problem like this. 
And a message from the developers list ("Re: known issues with 
current dll", 17 Mar 2001) where CF talks about a race condition between 
EOF and signal processing.

Here follow detailed results of my experimenting.

Send the manpage to a file:
$ man bash > mb
Use less to look at it:
$ less mb
No problems suspending/restarting.
Use a pipeline in a subshell to view it (the way "man" does it):
$ (cat mb | less)
Now we have the almost the same problem as I described in my first 
message - under xterm the 1st keypress sometimes goes to less instead of 
to bash, subsequently foregrounding the pipeline less doesn't redraw the 
screen properly, needs a newline after all commands, etc; under 
console the pipeline sometimes just dies without any error message.

More interestingly, if I don't put the pipeline in a subshell, then the 
problem changes, /and ceases to be intermittent/.
$ cat mb | less
Now the problem is the same whether in xterm or console: if I ^Z then the 
pipeline suspends (both processes shown by ps with an 'S', they stop 
responding to keypresses) but control doesn't return to bash, and the only 
way to unwedge things is to use "kill -CONT" from another window. 

Following the suggestion from Dario I tried playing around on a Linux box
I have access to. None of the effects descibed above could be replicated.
However, I *was* able to get a similar effect by using "kill -STOP" to
suspend the pipeline - this caused the same problems with less not
responding to keystrokes correctly upon putting it back in the foreground,
but I never managed to replicate control-not-returning-to-bash problem, no
matter what order I sent the signals, etc. If on the other hand I used
"kill -TSTP" on linux then I was unable to make anything interesting
occur, things just suspended and resumed just as they should.  If I sent a
TSTP to the subshell bash and to cat but not to less then the first
character I typed next would (sometimes?) go to less. Upon fg-ing less 
would be messed up as before. (Perhaps the race between EOF and signal 
that CF mentionned comes in here?)

Finally, I also tried using this "kill -STOP" and "kill -TSTP" on cygwin.  
First, if the pipeline is not in a subshell, with both STOP and TSTP, then
control doesn't return to bash (the same behaviour as with ^Z in cygwin,
different to what happened with linux). Second, if the pipeline is in a
subshell, then the behaviour is the same as with linux.

So it seems there are at possibly 2 problems with sending STOP/TSTP
signals to pipelines. If the pipeline is not in a subshell then the shell
gets wedged. If the pipeline is in a subshell, then it seems that
intermittently keyboard input (perhaps EOF) gets sent to less after the
TSTP reaching the subshell bash and cat but before the TSTP reaches less.  
This must be some kind of race condition, that happens in cygwin but not
in linux, although similar behaviour would occur in linux were it to be
the case that the keyboard input snuck in between the signals in the same
way.

Lev


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/