This is the mail archive of the
mailing list for the Cygwin project.
Re: Problem with select() on console
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
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.
Just a rough thought...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple