* mintty: Ctrl-Q does not work? @ 2012-09-25 12:10 Helmut Karlowski 2012-09-25 13:32 ` Thomas Wolff 2012-09-25 15:41 ` Ryan Johnson 0 siblings, 2 replies; 15+ messages in thread From: Helmut Karlowski @ 2012-09-25 12:10 UTC (permalink / raw) To: cygwin I type cat [some long ascii-file] then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be terminated by closing the window). Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin Can anybody reproduce this? -- Helmut Karlowski -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-09-25 12:10 mintty: Ctrl-Q does not work? Helmut Karlowski @ 2012-09-25 13:32 ` Thomas Wolff 2012-09-25 15:41 ` Ryan Johnson 1 sibling, 0 replies; 15+ messages in thread From: Thomas Wolff @ 2012-09-25 13:32 UTC (permalink / raw) To: cygwin On 25.09.2012 12:05, Helmut Karlowski wrote: > I type > > cat [some long ascii-file] > > then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be > terminated by closing the window). > > Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin > > Can anybody reproduce this? > Yes, and it seems to be an issue with cat, not mintty: cat x hangs grep . x works cat x | grep . works grep . x | cat hangs for seconds repeatedly even without ^S Killing the cat process sometimes works (releasing mintty), sometimes it claims "No such process" although it's in the task table (ps). ------ Thomas -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-09-25 12:10 mintty: Ctrl-Q does not work? Helmut Karlowski 2012-09-25 13:32 ` Thomas Wolff @ 2012-09-25 15:41 ` Ryan Johnson 2012-10-06 4:48 ` Andy Koppe 1 sibling, 1 reply; 15+ messages in thread From: Ryan Johnson @ 2012-09-25 15:41 UTC (permalink / raw) To: cygwin On 25/09/2012 6:05 AM, Helmut Karlowski wrote: > I type > > cat [some long ascii-file] > > then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be > terminated by closing the window). > > Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin > > Can anybody reproduce this? > Confirmed with mintty 1.1.1 and the same version of cygwin (w7-64). FWIW, doing it with `find .' rather than `cat' works fine. Regards, Ryan -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-09-25 15:41 ` Ryan Johnson @ 2012-10-06 4:48 ` Andy Koppe 2012-10-13 15:38 ` Christopher Faylor 0 siblings, 1 reply; 15+ messages in thread From: Andy Koppe @ 2012-10-06 4:48 UTC (permalink / raw) To: cygwin On 25 September 2012 14:32, Ryan Johnson wrote: > On 25/09/2012 6:05 AM, Helmut Karlowski wrote: >> >> I type >> >> cat [some long ascii-file] >> >> then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be >> terminated by closing the window). >> >> Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin >> >> Can anybody reproduce this? >> > Confirmed with mintty 1.1.1 and the same version of cygwin (w7-64). FWIW, > doing it with `find .' rather than `cat' works fine. The issue isn't specific to any of mintty, cat or Ctrl+S; for example, I've managed to reproduce it with xterm, hexdump, and just hitting Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't needed for the freeze to happen. In xterm I've even managed it with find, by hitting Enter repeatedly. If you then look at the situation in ps, you'll see something like this: O 3396 1 3396 1472 ? 1004 05:11:07 /usr/bin/xterm O 3528 4460 3528 528 pty3 1004 05:25:01 /usr/bin/cat The interesting bit there is the two 'O's in the first column, which means both processes are waiting to output. I think what's happening is that both of them are trying to write to their side of the underlying pty device, but that those writes are blocking until data is read from the other side of the pty. Result: deadlock. If the cat is killed (possibly with -9, because of its nine lives), the terminal happily continues on its way. So why doesn't this happen more often? Not sure. The speed difference between the client process output and the terminal seems to play a role here. I can only guess that the issue occurs if a buffer in the pty's slave->master pipe overflows and something is written to the master->slave pipe at the same time (which is unbuffered?). I don't understand the pty implementation enough to verify any of that, so cgf would need to comment further. Note besides: I couldn't make this deadlock happen on Ubuntu. Andy -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-06 4:48 ` Andy Koppe @ 2012-10-13 15:38 ` Christopher Faylor 2012-10-19 11:26 ` Andy Koppe 0 siblings, 1 reply; 15+ messages in thread From: Christopher Faylor @ 2012-10-13 15:38 UTC (permalink / raw) To: cygwin On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote: >On 25 September 2012 14:32, Ryan Johnson wrote: >> On 25/09/2012 6:05 AM, Helmut Karlowski wrote: >>> >>> I type >>> >>> cat [some long ascii-file] >>> >>> then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be >>> terminated by closing the window). >>> >>> Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin >>> >>> Can anybody reproduce this? >>> >> Confirmed with mintty 1.1.1 and the same version of cygwin (w7-64). FWIW, >> doing it with `find .' rather than `cat' works fine. > >The issue isn't specific to any of mintty, cat or Ctrl+S; for example, >I've managed to reproduce it with xterm, hexdump, and just hitting >Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't >needed for the freeze to happen. In xterm I've even managed it with >find, by hitting Enter repeatedly. > >If you then look at the situation in ps, you'll see something like this: > >O 3396 1 3396 1472 ? 1004 05:11:07 /usr/bin/xterm >O 3528 4460 3528 528 pty3 1004 05:25:01 /usr/bin/cat > >The interesting bit there is the two 'O's in the first column, which >means both processes are waiting to output. I think what's happening >is that both of them are trying to write to their side of the >underlying pty device, but that those writes are blocking until data >is read from the other side of the pty. Result: deadlock. If the cat >is killed (possibly with -9, because of its nine lives), the terminal >happily continues on its way. > >So why doesn't this happen more often? Not sure. The speed difference >between the client process output and the terminal seems to play a >role here. I can only guess that the issue occurs if a buffer in the >pty's slave->master pipe overflows and something is written to the >master->slave pipe at the same time (which is unbuffered?). > >I don't understand the pty implementation enough to verify any of >that, so cgf would need to comment further. Note besides: I couldn't >make this deadlock happen on Ubuntu. This should work in the latest snapshot. I added a polling kludge for 1.7.17 while I mull over the best way to handle this. cgf -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-13 15:38 ` Christopher Faylor @ 2012-10-19 11:26 ` Andy Koppe 2012-10-19 12:17 ` Corinna Vinschen 0 siblings, 1 reply; 15+ messages in thread From: Andy Koppe @ 2012-10-19 11:26 UTC (permalink / raw) To: cygwin On 13 October 2012 16:38, Christopher Faylor wrote: > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote: >>On 25 September 2012 14:32, Ryan Johnson wrote: >>> On 25/09/2012 6:05 AM, Helmut Karlowski wrote: >>>> >>>> I type >>>> >>>> cat [some long ascii-file] >>>> >>>> then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be >>>> terminated by closing the window). >>>> >>>> Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin >>>> >>>> Can anybody reproduce this? >>>> >>> Confirmed with mintty 1.1.1 and the same version of cygwin (w7-64). FWIW, >>> doing it with `find .' rather than `cat' works fine. >> >>The issue isn't specific to any of mintty, cat or Ctrl+S; for example, >>I've managed to reproduce it with xterm, hexdump, and just hitting >>Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't >>needed for the freeze to happen. In xterm I've even managed it with >>find, by hitting Enter repeatedly. >> >>If you then look at the situation in ps, you'll see something like this: >> >>O 3396 1 3396 1472 ? 1004 05:11:07 /usr/bin/xterm >>O 3528 4460 3528 528 pty3 1004 05:25:01 /usr/bin/cat >> >>The interesting bit there is the two 'O's in the first column, which >>means both processes are waiting to output. I think what's happening >>is that both of them are trying to write to their side of the >>underlying pty device, but that those writes are blocking until data >>is read from the other side of the pty. Result: deadlock. If the cat >>is killed (possibly with -9, because of its nine lives), the terminal >>happily continues on its way. >> >>So why doesn't this happen more often? Not sure. The speed difference >>between the client process output and the terminal seems to play a >>role here. I can only guess that the issue occurs if a buffer in the >>pty's slave->master pipe overflows and something is written to the >>master->slave pipe at the same time (which is unbuffered?). >> >>I don't understand the pty implementation enough to verify any of >>that, so cgf would need to comment further. Note besides: I couldn't >>make this deadlock happen on Ubuntu. > > This should work in the latest snapshot. I added a polling kludge for > 1.7.17 while I mull over the best way to handle this. Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat no longer freezes the terminal and that Ctrl+Q However, I still see the deadlock described above when hitting any other key that sends something, e.g. just Enter. Andy -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-19 11:26 ` Andy Koppe @ 2012-10-19 12:17 ` Corinna Vinschen 2012-10-19 15:00 ` Christopher Faylor 0 siblings, 1 reply; 15+ messages in thread From: Corinna Vinschen @ 2012-10-19 12:17 UTC (permalink / raw) To: cygwin On Oct 19 12:26, Andy Koppe wrote: > On 13 October 2012 16:38, Christopher Faylor wrote: > > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote: > >>The issue isn't specific to any of mintty, cat or Ctrl+S; for example, > >>I've managed to reproduce it with xterm, hexdump, and just hitting > >>Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't > >>needed for the freeze to happen. In xterm I've even managed it with > >>find, by hitting Enter repeatedly. > >> > >>If you then look at the situation in ps, you'll see something like this: > >> > >>O 3396 1 3396 1472 ? 1004 05:11:07 /usr/bin/xterm > >>O 3528 4460 3528 528 pty3 1004 05:25:01 /usr/bin/cat > >> > >>The interesting bit there is the two 'O's in the first column, which > >>means both processes are waiting to output. I think what's happening > >>is that both of them are trying to write to their side of the > >>underlying pty device, but that those writes are blocking until data > >>is read from the other side of the pty. Result: deadlock. If the cat > >>is killed (possibly with -9, because of its nine lives), the terminal > >>happily continues on its way. > >> > >>So why doesn't this happen more often? Not sure. The speed difference > >>between the client process output and the terminal seems to play a > >>role here. I can only guess that the issue occurs if a buffer in the > >>pty's slave->master pipe overflows and something is written to the > >>master->slave pipe at the same time (which is unbuffered?). > >> > >>I don't understand the pty implementation enough to verify any of > >>that, so cgf would need to comment further. Note besides: I couldn't > >>make this deadlock happen on Ubuntu. > > > > This should work in the latest snapshot. I added a polling kludge for > > 1.7.17 while I mull over the best way to handle this. > > Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat > no longer freezes the terminal and that Ctrl+Q > > However, I still see the deadlock described above when hitting any > other key that sends something, e.g. just Enter. Too bad. Are you sure? I tried really hard to get a deadlock and could not reproduce it anymore under W7. My Enter key is still on paracetamol. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-19 12:17 ` Corinna Vinschen @ 2012-10-19 15:00 ` Christopher Faylor 2012-10-21 4:38 ` Andy Koppe 0 siblings, 1 reply; 15+ messages in thread From: Christopher Faylor @ 2012-10-19 15:00 UTC (permalink / raw) To: cygwin On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote: >On Oct 19 12:26, Andy Koppe wrote: >> On 13 October 2012 16:38, Christopher Faylor wrote: >> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote: >> >>The issue isn't specific to any of mintty, cat or Ctrl+S; for example, >> >>I've managed to reproduce it with xterm, hexdump, and just hitting >> >>Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't >> >>needed for the freeze to happen. In xterm I've even managed it with >> >>find, by hitting Enter repeatedly. >> >> >> >>If you then look at the situation in ps, you'll see something like this: >> >> >> >>O 3396 1 3396 1472 ? 1004 05:11:07 /usr/bin/xterm >> >>O 3528 4460 3528 528 pty3 1004 05:25:01 /usr/bin/cat >> >> >> >>The interesting bit there is the two 'O's in the first column, which >> >>means both processes are waiting to output. I think what's happening >> >>is that both of them are trying to write to their side of the >> >>underlying pty device, but that those writes are blocking until data >> >>is read from the other side of the pty. Result: deadlock. If the cat >> >>is killed (possibly with -9, because of its nine lives), the terminal >> >>happily continues on its way. >> >> >> >>So why doesn't this happen more often? Not sure. The speed difference >> >>between the client process output and the terminal seems to play a >> >>role here. I can only guess that the issue occurs if a buffer in the >> >>pty's slave->master pipe overflows and something is written to the >> >>master->slave pipe at the same time (which is unbuffered?). >> >> >> >>I don't understand the pty implementation enough to verify any of >> >>that, so cgf would need to comment further. Note besides: I couldn't >> >>make this deadlock happen on Ubuntu. >> > >> > This should work in the latest snapshot. I added a polling kludge for >> > 1.7.17 while I mull over the best way to handle this. >> >> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat >> no longer freezes the terminal and that Ctrl+Q >> >> However, I still see the deadlock described above when hitting any >> other key that sends something, e.g. just Enter. > >Too bad. Are you sure? I tried really hard to get a deadlock and could >not reproduce it anymore under W7. My Enter key is still on paracetamol. I can't duplicate it either. I do notice that Cygwin doesn't work like UNIX in that characters are still echoed after CTRL-S is hit. That's wrong but it looks like making it right will require major surgery. Must. Resist. YA. Pty. Rewrite. cgf -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-19 15:00 ` Christopher Faylor @ 2012-10-21 4:38 ` Andy Koppe 2012-10-21 5:44 ` Christopher Faylor 0 siblings, 1 reply; 15+ messages in thread From: Andy Koppe @ 2012-10-21 4:38 UTC (permalink / raw) To: cygwin On 19 October 2012 16:00, Christopher Faylor wrote: > On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote: >>On Oct 19 12:26, Andy Koppe wrote: >>> On 13 October 2012 16:38, Christopher Faylor wrote: >>> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote: >>> >>The issue isn't specific to any of mintty, cat or Ctrl+S; for example, >>> >>I've managed to reproduce it with xterm, hexdump, and just hitting >>> >>Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't >>> >>needed for the freeze to happen. In xterm I've even managed it with >>> >>find, by hitting Enter repeatedly. >>> >> >>> >>If you then look at the situation in ps, you'll see something like this: >>> >> >>> >>O 3396 1 3396 1472 ? 1004 05:11:07 /usr/bin/xterm >>> >>O 3528 4460 3528 528 pty3 1004 05:25:01 /usr/bin/cat >>> >> >>> >>The interesting bit there is the two 'O's in the first column, which >>> >>means both processes are waiting to output. I think what's happening >>> >>is that both of them are trying to write to their side of the >>> >>underlying pty device, but that those writes are blocking until data >>> >>is read from the other side of the pty. Result: deadlock. If the cat >>> >>is killed (possibly with -9, because of its nine lives), the terminal >>> >>happily continues on its way. >>> >> >>> >>So why doesn't this happen more often? Not sure. The speed difference >>> >>between the client process output and the terminal seems to play a >>> >>role here. I can only guess that the issue occurs if a buffer in the >>> >>pty's slave->master pipe overflows and something is written to the >>> >>master->slave pipe at the same time (which is unbuffered?). >>> >> >>> >>I don't understand the pty implementation enough to verify any of >>> >>that, so cgf would need to comment further. Note besides: I couldn't >>> >>make this deadlock happen on Ubuntu. >>> > >>> > This should work in the latest snapshot. I added a polling kludge for >>> > 1.7.17 while I mull over the best way to handle this. >>> >>> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat >>> no longer freezes the terminal and that Ctrl+Q >>> >>> However, I still see the deadlock described above when hitting any >>> other key that sends something, e.g. just Enter. >> >>Too bad. Are you sure? I tried really hard to get a deadlock and could >>not reproduce it anymore under W7. My Enter key is still on paracetamol. > > I can't duplicate it either. Sorry I didn't get round to have another look at this before the 1.7.17 release. I found that it's the CYGWIN=pipe_byte option that makes the difference. In 1.7.16, the deadlock occurs with and without that option. It 1.7.17, it only occurs with pipe_byte enabled. Andy -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-21 4:38 ` Andy Koppe @ 2012-10-21 5:44 ` Christopher Faylor 2012-10-28 6:24 ` Andy Koppe 0 siblings, 1 reply; 15+ messages in thread From: Christopher Faylor @ 2012-10-21 5:44 UTC (permalink / raw) To: cygwin On Sun, Oct 21, 2012 at 05:38:11AM +0100, Andy Koppe wrote: >On 19 October 2012 16:00, Christopher Faylor wrote: >> On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote: >>>On Oct 19 12:26, Andy Koppe wrote: >>>> On 13 October 2012 16:38, Christopher Faylor wrote: >>>> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote: >>>> >>The issue isn't specific to any of mintty, cat or Ctrl+S; for example, >>>> >>I've managed to reproduce it with xterm, hexdump, and just hitting >>>> >>Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't >>>> >>needed for the freeze to happen. In xterm I've even managed it with >>>> >>find, by hitting Enter repeatedly. >>>> >> >>>> >>If you then look at the situation in ps, you'll see something like this: >>>> >> >>>> >>O 3396 1 3396 1472 ? 1004 05:11:07 /usr/bin/xterm >>>> >>O 3528 4460 3528 528 pty3 1004 05:25:01 /usr/bin/cat >>>> >> >>>> >>The interesting bit there is the two 'O's in the first column, which >>>> >>means both processes are waiting to output. I think what's happening >>>> >>is that both of them are trying to write to their side of the >>>> >>underlying pty device, but that those writes are blocking until data >>>> >>is read from the other side of the pty. Result: deadlock. If the cat >>>> >>is killed (possibly with -9, because of its nine lives), the terminal >>>> >>happily continues on its way. >>>> >> >>>> >>So why doesn't this happen more often? Not sure. The speed difference >>>> >>between the client process output and the terminal seems to play a >>>> >>role here. I can only guess that the issue occurs if a buffer in the >>>> >>pty's slave->master pipe overflows and something is written to the >>>> >>master->slave pipe at the same time (which is unbuffered?). >>>> >> >>>> >>I don't understand the pty implementation enough to verify any of >>>> >>that, so cgf would need to comment further. Note besides: I couldn't >>>> >>make this deadlock happen on Ubuntu. >>>> > >>>> > This should work in the latest snapshot. I added a polling kludge for >>>> > 1.7.17 while I mull over the best way to handle this. >>>> >>>> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat >>>> no longer freezes the terminal and that Ctrl+Q >>>> >>>> However, I still see the deadlock described above when hitting any >>>> other key that sends something, e.g. just Enter. >>> >>>Too bad. Are you sure? I tried really hard to get a deadlock and could >>>not reproduce it anymore under W7. My Enter key is still on paracetamol. >> >> I can't duplicate it either. > >Sorry I didn't get round to have another look at this before the 1.7.17 release. > >I found that it's the CYGWIN=pipe_byte option that makes the >difference. In 1.7.16, the deadlock occurs with and without that >option. It 1.7.17, it only occurs with pipe_byte enabled. Still can't duplicate it. pipe_byte was designed to be used only with anonymous pipes and not with ptys so it shouldn't have any effect on pty handling. cgf -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-21 5:44 ` Christopher Faylor @ 2012-10-28 6:24 ` Andy Koppe 2012-10-28 17:17 ` Helmut Karlowski 0 siblings, 1 reply; 15+ messages in thread From: Andy Koppe @ 2012-10-28 6:24 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 4378 bytes --] On 21 October 2012 06:44, Christopher Faylor wrote: > On Sun, Oct 21, 2012 at 05:38:11AM +0100, Andy Koppe wrote: >>On 19 October 2012 16:00, Christopher Faylor wrote: >>> On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote: >>>>On Oct 19 12:26, Andy Koppe wrote: >>>>> On 13 October 2012 16:38, Christopher Faylor wrote: >>>>> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote: >>>>> >>The issue isn't specific to any of mintty, cat or Ctrl+S; for example, >>>>> >>I've managed to reproduce it with xterm, hexdump, and just hitting >>>>> >>Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't >>>>> >>needed for the freeze to happen. In xterm I've even managed it with >>>>> >>find, by hitting Enter repeatedly. >>>>> >> >>>>> >>If you then look at the situation in ps, you'll see something like this: >>>>> >> >>>>> >>O 3396 1 3396 1472 ? 1004 05:11:07 /usr/bin/xterm >>>>> >>O 3528 4460 3528 528 pty3 1004 05:25:01 /usr/bin/cat >>>>> >> >>>>> >>The interesting bit there is the two 'O's in the first column, which >>>>> >>means both processes are waiting to output. I think what's happening >>>>> >>is that both of them are trying to write to their side of the >>>>> >>underlying pty device, but that those writes are blocking until data >>>>> >>is read from the other side of the pty. Result: deadlock. If the cat >>>>> >>is killed (possibly with -9, because of its nine lives), the terminal >>>>> >>happily continues on its way. >>>>> >> >>>>> >>So why doesn't this happen more often? Not sure. The speed difference >>>>> >>between the client process output and the terminal seems to play a >>>>> >>role here. I can only guess that the issue occurs if a buffer in the >>>>> >>pty's slave->master pipe overflows and something is written to the >>>>> >>master->slave pipe at the same time (which is unbuffered?). >>>>> >> >>>>> >>I don't understand the pty implementation enough to verify any of >>>>> >>that, so cgf would need to comment further. Note besides: I couldn't >>>>> >>make this deadlock happen on Ubuntu. >>>>> > >>>>> > This should work in the latest snapshot. I added a polling kludge for >>>>> > 1.7.17 while I mull over the best way to handle this. >>>>> >>>>> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat >>>>> no longer freezes the terminal and that Ctrl+Q >>>>> >>>>> However, I still see the deadlock described above when hitting any >>>>> other key that sends something, e.g. just Enter. >>>> >>>>Too bad. Are you sure? I tried really hard to get a deadlock and could >>>>not reproduce it anymore under W7. My Enter key is still on paracetamol. >>> >>> I can't duplicate it either. >> >>Sorry I didn't get round to have another look at this before the 1.7.17 release. >> >>I found that it's the CYGWIN=pipe_byte option that makes the >>difference. In 1.7.16, the deadlock occurs with and without that >>option. It 1.7.17, it only occurs with pipe_byte enabled. > > Still can't duplicate it. pipe_byte was designed to be used only with > anonymous pipes and not with ptys so it shouldn't have any effect on > pty handling. You're right, on further tests, pipe_byte doesn't matter. Not sure what happened; a case of seeing what one expects to see, probably. Sorry. However, I can still reproduce the issue (without pipe_byte), and I did a fresh Cygwin install into the default location to try to minimise variables. Cygcheck output attached. Here's what I did: - Make sure no Cygwin processes are running. - Open the "Cygwin Terminal" desktop shortcut - cd to the winsup/cygwin directory in a pre-existing checkout of the Cygwin sources - cat *.cc - Hit Enter once: output stops, soon after the terminal window goes grey and "(Not Responding)" is added to the window title. (I'd also had cases where I had to hit Enter repeatedly to make this happen.) - Open another terminal. - ps > O 224 3792 224 2884 pty0 1004 06:14:33 /usr/bin/cat > O 1544 1 1544 1544 ? 1004 06:08:36 /usr/bin/mintty - kill 224: first window comes back to life, with output ending like this: > ntdev, S_IFBLK, true}, > {"/dev/sdcf4", BRACK(FH_SDCF | 4), "\\Device\\Harddisk83\\Partition4", exists_ntdev, >S_IFBLK, true}, > {"/dev/sdcf5", B >Terminated Please let me know if I can provide anything else. Regards, Andy [-- Attachment #2: cygcheck.out --] [-- Type: application/octet-stream, Size: 11547 bytes --] Cygwin Configuration Diagnostics Current System Time: Sun Oct 28 06:58:03 2012 Windows 7 Professional N Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\Program Files (x86)\PC Connectivity Solution C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 Output from C:\cygwin\bin\id.exe UID: 1004(Andy) GID: 513(None) 513(None) 545(Users) 1000(HomeUsers) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'Andy' PWD = '/home/Andy' HOME = '/home/Andy' HOMEPATH = '\Users\Andy' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Users\Andy\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'Talisker' SHELL = '/bin/bash' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'AMD64 Family 15 Model 72 Stepping 2, AuthenticAMD' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/cygdrive/c/Users/Andy/Desktop' USERDOMAIN = 'TALISKER' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\' !:: = '::\' temp = 'C:\Users\Andy\AppData\Local\Temp' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' TMP = '/tmp' USERNAME = 'Andy' PROCESSOR_LEVEL = '15' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' LANG = 'en_US.UTF-8' USERPROFILE = 'C:\Users\Andy' TZ = 'Europe/London' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\TALISKER' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\Andy\AppData\Local' ProgramData = 'C:\ProgramData' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' PRINTER = 'HP LaserJet P1006' PROCESSOR_REVISION = '4802' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '2' asl.log = 'Destination=file' SESSIONNAME = 'Console' COMPUTERNAME = 'TALISKER' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:' 26a8341cd07d8d52 = '\??\C:\cyg179' c5e39b7a9d22bafb = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: a46ac466ed629d62 Path: C: System: Key: 26a8341cd07d8d52 Path: C:\cyg179 System: Key: c5e39b7a9d22bafb Path: C:\cygwin User: Key: c5e39b7a9d22bafb Path: C:\cygwin c: hd NTFS 32763Mb 97% CP CS UN PA FC Seven d: hd NTFS 119859Mb 68% CP CS UN PA FC Vista C:\cygwin / system binary,auto C:\cygwin\bin /usr/bin system binary,auto C:\cygwin\lib /usr/lib system binary,auto cygdrive prefix /cygdrive user binary,auto Found: C:\cygwin\bin\awk -> C:\cygwin\bin\gawk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Not Found: cpp (good!) Not Found: crontab Found: C:\cygwin\bin\find.exe Found: C:\Windows\system32\find.exe Warning: C:\cygwin\bin\find.exe hides C:\Windows\system32\find.exe Not Found: gcc Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Not Found: ld Found: C:\cygwin\bin\ls.exe Not Found: make Found: C:\cygwin\bin\mv.exe Not Found: patch Not Found: perl Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Not Found: ssh Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\test.exe Not Found: vi Not Found: vim 14k 2012/05/04 C:\cygwin\bin\cygattr-1.dll - os=4.0 img=1.0 sys=4.0 "cygattr-1.dll" v0.0 ts=2012/5/4 12:35 62k 2011/05/21 C:\cygwin\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0 "cygbz2-1.dll" v0.0 ts=2011/5/21 20:16 43k 2010/01/02 C:\cygwin\bin\cygform-10.dll - os=4.0 img=1.0 sys=4.0 "cygform-10.dll" v0.0 ts=2010/1/2 14:49 47k 2010/01/02 C:\cygwin\bin\cygformw-10.dll - os=4.0 img=1.0 sys=4.0 "cygformw-10.dll" v0.0 ts=2010/1/2 17:31 79k 2011/10/26 C:\cygwin\bin\cyggcc_s-1.dll - os=4.0 img=1.0 sys=4.0 "cyggcc_s-1.dll" v0.0 ts=2011/10/23 14:15 317k 2011/07/31 C:\cygwin\bin\cyggmp-3.dll - os=4.0 img=1.0 sys=4.0 "cyggmp-3.dll" v0.0 ts=2011/7/31 6:14 25k 2012/05/04 C:\cygwin\bin\cyghistory7.dll - os=4.0 img=1.0 sys=4.0 "cyghistory7.dll" v0.0 ts=2012/5/4 22:07 358k 2012/04/14 C:\cygwin\bin\cygicons-0.dll - os=4.0 img=1.4 sys=4.0 "cygicons-0.dll" v0.0 ts=2012/4/14 2:48 985k 2011/10/16 C:\cygwin\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0 "cygiconv-2.dll" v0.0 ts=2011/10/16 18:01 35k 2011/10/16 C:\cygwin\bin\cygintl-8.dll - os=4.0 img=1.0 sys=4.0 "cygintl-8.dll" v0.0 ts=2011/10/16 6:38 6k 2012/10/19 C:\cygwin\bin\cyglsa.dll - os=4.0 img=1.0 sys=4.0 "cyglsa.dll" v0.0 ts=2012/10/19 13:40 9k 2012/10/19 C:\cygwin\bin\cyglsa64.dll - os=5.2 img=0.0 sys=5.2 123k 2011/05/19 C:\cygwin\bin\cyglzma-5.dll - os=4.0 img=1.0 sys=4.0 "cyglzma-5.dll" v0.0 ts=2011/5/19 3:41 94k 2012/04/22 C:\cygwin\bin\cygmagic-1.dll - os=4.0 img=1.0 sys=4.0 "cygmagic-1.dll" v0.0 ts=2012/4/22 19:09 25k 2010/01/02 C:\cygwin\bin\cygmenu-10.dll - os=4.0 img=1.0 sys=4.0 "cygmenu-10.dll" v0.0 ts=2010/1/2 14:48 25k 2010/01/02 C:\cygwin\bin\cygmenuw-10.dll - os=4.0 img=1.0 sys=4.0 "cygmenuw-10.dll" v0.0 ts=2010/1/2 17:30 213k 2011/07/31 C:\cygwin\bin\cygmp-3.dll - os=4.0 img=1.0 sys=4.0 "cygmp-3.dll" v0.0 ts=2011/7/31 6:12 63k 2010/01/02 C:\cygwin\bin\cygncurses++-10.dll - os=4.0 img=1.0 sys=4.0 "cygncurses++-10.dll" v0.0 ts=2010/1/2 15:00 63k 2010/01/02 C:\cygwin\bin\cygncurses++w-10.dll - os=4.0 img=1.0 sys=4.0 "cygncurses++w-10.dll" v0.0 ts=2010/1/2 17:41 195k 2010/01/02 C:\cygwin\bin\cygncurses-10.dll - os=4.0 img=1.0 sys=4.0 "cygncurses-10.dll" v0.0 ts=2010/1/2 14:45 244k 2010/01/02 C:\cygwin\bin\cygncursesw-10.dll - os=4.0 img=1.0 sys=4.0 "cygncursesw-10.dll" v0.0 ts=2010/1/2 17:28 13k 2010/01/02 C:\cygwin\bin\cygpanel-10.dll - os=4.0 img=1.0 sys=4.0 "cygpanel-10.dll" v0.0 ts=2010/1/2 14:47 13k 2010/01/02 C:\cygwin\bin\cygpanelw-10.dll - os=4.0 img=1.0 sys=4.0 "cygpanelw-10.dll" v0.0 ts=2010/1/2 16:30 255k 2012/02/10 C:\cygwin\bin\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0 "cygpcre-0.dll" v0.0 ts=2012/2/10 10:24 22k 2002/06/09 C:\cygwin\bin\cygpopt-0.dll - os=4.0 img=1.0 sys=4.0 "cygpopt-0.dll" v0.0 ts=2002/6/9 6:45 162k 2012/05/04 C:\cygwin\bin\cygreadline7.dll - os=4.0 img=1.0 sys=4.0 "cygreadline7.dll" v0.0 ts=2012/5/4 22:07 8k 2011/05/05 C:\cygwin\bin\cygsigsegv-2.dll - os=4.0 img=1.0 sys=4.0 "cygsigsegv-2.dll" v0.0 ts=2011/5/5 8:33 780k 2011/10/26 C:\cygwin\bin\cygstdc++-6.dll - os=4.0 img=1.0 sys=4.0 "cygstdc++-6.dll" v0.0 ts=2011/10/23 14:58 48k 2010/01/02 C:\cygwin\bin\cygtic-10.dll - os=4.0 img=1.0 sys=4.0 "cygtic-10.dll" v0.0 ts=2010/1/2 14:45 48k 2010/01/02 C:\cygwin\bin\cygticw-10.dll - os=4.0 img=1.0 sys=4.0 "cygticw-10.dll" v0.0 ts=2010/1/2 17:28 71k 2012/05/13 C:\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0 "cygz.dll" v0.0 ts=2012/5/13 5:11 2791k 2012/10/19 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0 ts=2012/10/19 13:39 Cygwin DLL version info: DLL version: 1.7.17 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 262 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 Can't find the cygrunsrv utility, skipping services check. Cygwin Package Information Last downloaded files to: C:\tmp Last downloaded files from: http://ftp.inf.tu-dresden.de/software/windows/cygwin32/ Package Version Status _autorebase 000149-1 OK _update-info-dir 01084-1 OK alternatives 1.3.30c-10 OK apngopt 1.1-1 OK base-cygwin 3.1-1 OK base-files 4.1-1 OK bash 4.1.10-4 OK bzip2 1.0.6-2 OK coreutils 8.15-1 OK cygutils 1.4.10-2 OK cygwin 1.7.17-1 OK cygwin-doc 1.7-1 OK dash 0.5.7-1 OK diffutils 3.2-1 OK dos2unix 6.0.2-1 OK editrights 1.01-2 OK file 5.11-1 OK findutils 4.5.9-2 OK gawk 4.0.1-1 OK gettext 0.18.1.1-2 OK grep 2.6.3-1 OK groff 1.21-2 OK gzip 1.4-1 OK ipc-utils 1.0-1 OK less 444-1 OK libattr1 2.4.46-1 OK libbz2_1 1.0.6-2 OK libgcc1 4.5.3-3 OK libgmp3 4.3.2-1 OK libiconv2 1.14-2 OK libintl8 0.18.1.1-2 OK liblzma5 5.0.2_20110517-1 OK libncurses10 5.7-18 OK libncursesw10 5.7-18 OK libpcre0 8.21-2 OK libpopt0 1.6.4-4 OK libreadline7 6.1.2-3 OK libsigsegv2 2.10-1 OK libstdc++6 4.5.3-3 OK login 1.10-10 OK man 1.6g-1 OK mintty 1.1.2-1 OK rebase 4.3.0-1 OK run 1.1.13-1 OK sed 4.2.1-2 OK tar 1.26-1 OK terminfo 5.7_20091114-14 OK texinfo 4.13-4 OK tzcode 2012e-1 OK which 2.20-2 OK xz 5.0.2_20110517-1 OK zlib0 1.2.7-1 OK Use -h to see help about each section [-- Attachment #3: Type: text/plain, Size: 218 bytes --] -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-28 6:24 ` Andy Koppe @ 2012-10-28 17:17 ` Helmut Karlowski 2012-10-28 17:32 ` Christopher Faylor 2012-10-29 12:49 ` Charles Stepp 0 siblings, 2 replies; 15+ messages in thread From: Helmut Karlowski @ 2012-10-28 17:17 UTC (permalink / raw) To: cygwin Andy Koppe, 28.10.2012 07:24:04: > However, I can still reproduce the issue (without pipe_byte), and I > did a fresh Cygwin install into the default location to try to > minimise variables. Cygcheck output attached. I just installed the latest cygwin-release. Ctrl-S,Ctrl-Q works as expected, but e.g. Enter stops output and freezes the terminal like before (need to kill -9 the involved process). Why is there any reaction on Enter at all? -- Helmut Karlowski -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-28 17:17 ` Helmut Karlowski @ 2012-10-28 17:32 ` Christopher Faylor 2012-10-29 12:49 ` Charles Stepp 1 sibling, 0 replies; 15+ messages in thread From: Christopher Faylor @ 2012-10-28 17:32 UTC (permalink / raw) To: cygwin On Sun, Oct 28, 2012 at 06:17:27PM +0100, Helmut Karlowski wrote: >Andy Koppe, 28.10.2012 07:24:04: > >> However, I can still reproduce the issue (without pipe_byte), and I >> did a fresh Cygwin install into the default location to try to >> minimise variables. Cygcheck output attached. > >I just installed the latest cygwin-release. Ctrl-S,Ctrl-Q works as >expected, but e.g. Enter stops output and freezes the terminal like before >(need to kill -9 the involved process). Why is there any reaction on Enter >at all? It's what we in the software industry call "a bug". -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: mintty: Ctrl-Q does not work? 2012-10-28 17:17 ` Helmut Karlowski 2012-10-28 17:32 ` Christopher Faylor @ 2012-10-29 12:49 ` Charles Stepp 2012-10-29 14:34 ` Christopher Faylor 1 sibling, 1 reply; 15+ messages in thread From: Charles Stepp @ 2012-10-29 12:49 UTC (permalink / raw) To: Helmut Karlowski, cygwin > Andy Koppe, 28.10.2012 07:24:04: > > > However, I can still reproduce the issue (without pipe_byte), and I > > did a fresh Cygwin install into the default location to try to > > minimise variables. Cygcheck output attached. > > I just installed the latest cygwin-release. Ctrl-S,Ctrl-Q works as expected, but e.g. Enter stops output and freezes the terminal like before (need to kill -9 the involved process). Why is there any reaction on Enter at all? > > -- > Helmut Karlowski The stty ixany setting determines whether any key or the start key (Ctl-Q) resumes output after a stop key (Ctl-S). stty ixany enables resuming output with any key. stty -ixany sets it such that only the start key (Ctl-Q) resumes output. -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mintty: Ctrl-Q does not work? 2012-10-29 12:49 ` Charles Stepp @ 2012-10-29 14:34 ` Christopher Faylor 0 siblings, 0 replies; 15+ messages in thread From: Christopher Faylor @ 2012-10-29 14:34 UTC (permalink / raw) To: cygwin On Mon, Oct 29, 2012 at 12:49:24PM +0000, Charles Stepp wrote: >> Andy Koppe, 28.10.2012 07:24:04: >> >> > However, I can still reproduce the issue (without pipe_byte), and I >> > did a fresh Cygwin install into the default location to try to >> > minimise variables. Cygcheck output attached. >> >>I just installed the latest cygwin-release. Ctrl-S,Ctrl-Q works as >>expected, but e.g. Enter stops output and freezes the terminal like >>before (need to kill -9 the involved process). Why is there any >>reaction on Enter at all? > >The stty ixany setting determines whether any key or the start key >(Ctl-Q) resumes output after a stop key (Ctl-S). > >stty ixany enables resuming output with any key. >stty -ixany sets it such that only the start key (Ctl-Q) resumes output. There was no "Ctl-S" in the above description. -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-10-29 14:34 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-09-25 12:10 mintty: Ctrl-Q does not work? Helmut Karlowski 2012-09-25 13:32 ` Thomas Wolff 2012-09-25 15:41 ` Ryan Johnson 2012-10-06 4:48 ` Andy Koppe 2012-10-13 15:38 ` Christopher Faylor 2012-10-19 11:26 ` Andy Koppe 2012-10-19 12:17 ` Corinna Vinschen 2012-10-19 15:00 ` Christopher Faylor 2012-10-21 4:38 ` Andy Koppe 2012-10-21 5:44 ` Christopher Faylor 2012-10-28 6:24 ` Andy Koppe 2012-10-28 17:17 ` Helmut Karlowski 2012-10-28 17:32 ` Christopher Faylor 2012-10-29 12:49 ` Charles Stepp 2012-10-29 14:34 ` Christopher Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).