This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with select() on console

On Thu, Jul 15, 2010 at 09:54:21AM +0200, Matthias Andree wrote:
>Am 15.07.2010, 07:49 Uhr, schrieb Christopher Faylor:
>> On Thu, Jul 15, 2010 at 01:44:19AM +0100, Cliff Hones wrote:
>>> When select() is used to test for input availability on the standard
>>> cygwin console in normal (cooked) mode, it indicates input is available
>>> as soon as any key is pressed.  However, a call to read(0,...)
>>> will (correctly) block until a terminating RETURN is entered.
>>> select() should only indicate input is available when a call
>>> to read would *not* block - ie when a read call will immediately
>>> return at least one character or an error such as EOF.
>>> The behaviour of the following test case illustrates this.  When run
>>> in a console window typing a single key causes the program to wait
>>> for the whole line.  When run under mintty or on Linux the
>>> select() calls will continue to return no input until RETURN is
>>> entered.
>> Since, AFAIK, Windows has no way to do this, I don't see how it could be
>> done easily.  You could, I guess, pull characters into a buffer until a
>> newline was found but that would be pretty error-prone and any use of
>> select() would potentially invalidate console i/o for subprocesses.
>> So, I don't see this changing anytime soon.
>Is there a way to detect that the application is run from a Windows  
>console rather than mintty?
>If so, cygwin1.dll could print a warning to the console, (something along  
>the lines that running the application under some X11 terminal or mintty  
>is advised) and return EINVAL, or abort the application, in either case if  
>POSIXLY_CORRECT is set in the environment, much like some GNU tools will  
>switch to a more POSIX compliant behaviour with that variable.

Print a warning to the console if something uses select???  Nuh uh.

This behavior has been in existence for more than ten years.  I think I'll
opt for explaining it once every ten years instead.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]