Heath Kehoe wrote on 2010-12-02: > On Dec 2, 2010, at 1:59 PM, Andy Koppe wrote: >> On 2 December 2010 18:40, Charles Wilson wrote: >>> On 12/2/2010 1:27 PM, David Rothenberger wrote: >>>> Illia Bobyr wrote: >>>>> On 12/1/2010 8:53 PM, David Rothenberger wrote: >>>>>> Try typing "reset" or "stty sane" (without the quotes) and pressing >>>>>> Enter. You won't see what you're typing, but after the shell should >>>>>> work again. >>>>> >>>>> Would you, please, elaborate on this a little bit? >>>>> Maybe a link or a reference that explains why this is happening? >>>> >>>> I'm sorry, I can't. I don't know why it is happening. I just know how >>>> to recover from it as a user. >>> >>> I've noticed that this misbehavior occurs more frequently these days: >>> ctrl-c'ing some tasks (tail, less, maybe a few others) ends up with >>> the terminal settings all scrogged up >> >> FWIW, I can't reproduce this, even if I kill the tail or less with >> SIGKILL, thus giving them no chance to do any cleanup. (I assume you >> use 'less -K' to allow it to be ctrl-c'ed?) >> >> Which shell do people who've seen the problem use? Is it an >> intermittent issue? >> > > If you SIGKILL a 'less' while it has the tty set for raw/noecho then > the tty will stay in that mode. Bash apparently resets the tty to > normal for you after the process is killed (actually, bash's readline > normally runs the tty in a psuedo-raw mode [-icanon min=1 -echo] as a > matter of course). If you run 'less' from an 'ash' shell then SIGKILL > it, the ash shell will need 'stty sane' typed in. > > Also, the OP said the problem was happening on pipelines like 'tail | > grep'. Neither tail nor grep muck with tty settings (that I know of), > so if the tty is ending up with echo disabled, it's got to be the shell > leaving it that way. Perhaps there's some kind of race condition in the > shell's signal processing? So again, we'll need to know which shell > this is happening with and a way to reliably repro the issue to have > any hope of fixing it.
My shell is bash. I see the problem rarely after I Ctrl-C out of 'tail -f <filename>' (sometimes <filename> is a symlink to the actual file). Most of the time, everything works fine, though. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple