unable to type command into Cygwin after running 'tail'
Thu Dec 2 22:21:00 GMT 2010
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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin