Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: ares.its.yale.edu: lsb32 owned process doing -bs Date: Thu, 29 May 2003 23:02:59 -0400 (EDT) From: Lev Bishop To: cygwin AT cygwin DOT com Subject: Re: problem suspending "man bash" (intermittent) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-YaleITSMailFilter: Version 1.0c (attachment(s) not renamed) 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/