On Thu, Jul 15, 2010 at 01:45:43PM +0100, Cliff Hones wrote: >Cliff Hones wrote: >> I must look at the console source... > >And now I have, and I see that fhandler_console does its own line >editing, so is perfectly aware of the input line state. So blocking as >soon as any key is typed seems a shortcoming of cygwin, not windows?
You could say that about just about everything that Cygwin has problems with. For instance, the fact that Cygwin's ptys aren't properly recognized by pure Windows programs is a limitation of Cygwin too. It really isn't an interesting distinction since it boils down to a cost/benefit situation. >I see there may be a difficulty with storing incomplete lines, or with >synchronizing processing of new console events seen by different cygwin >threads/processes, and it may be deemed unworthwhile (especially as it >doesn't seem to be a frequently raised question), but to it seems >doable. The readahead stuff in fhandler_console.cc (which I wrote) was intended to be used for small amounts of data. Extending it to properly handle cooked mode would be quite an undertaking. Since, as Andy pointed out, most sophisticated applications used something like readline, this has not come up previously that I can recall. So, this is a PTC case. 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
