The Gnu Emacs and Cygwin tty problem has been haunting me since
I have started using them the first day. I did not understand
the cause of the problem at that time. After sufficient researches,
I think I have now understood the cause of it, but I have no solution to it.
Hopefully someone brilliant can solve the problem for me.
TTY Problem on Gnu Emacs
For Gnu Emacs running in Windows, if a shell is invoked
(regardless of cmd.exe shell, emacs eshell or cygwin bash shell),
the shell is not run under a tty terminal.
This can be verified by invoking the tty.exe command distributed with
cygwin. The output from the tty.exe command simply says "not a tty".
(For Gnu Emacs running in Unix environment, tty command says "/dev/ttyN".)
If an application is not invoked within a tty terminal, usually the
application assumes that its output is redirected to a file. The application
will buffer the output. This means the output will not be flushed until
a sufficient amount of output has accumulated.
TTY Problem on Cygwin rxvt
Considered the following simple buffer.c program.
int main(int argc, char** argv)
if( _isatty( _fileno( stdout ) ) )
printf( "stdout has not been redirected to a file\n" );
printf( "stdout has been redirected to a file\n");
Running Cygwin Bash shell under Cygwin rxvt terminal, the TTY problem appears when running the .exe of buffer.c generated by Microsoft Visual C compiler or using Cygwin gcc with -mno-cygwin option.
Under the same settings, running the .exe of buffer.c generated by Cygwin gcc does not exhibit any problem.
The "tty" command executed in a rxvt Bash Shell says that it is "/dev/ttyN". This is to say that .exe generated by Microsoft Visual C compiler or using Cygwin gcc with -mno-cygwin option does not respect the tty settings.
In short, all Cygwin applications work well in a rxvt terminal. All Windows
applications that do not involve user inputs work in a rxvt terminal as well.
The problem is with all Windows applications that require user inputs.
(assuming xxxx is your input)
More information about this problem
I do not know the solution. The workaround is to run Windows applications that
require user inputs in a Cygwin Bash shell in a Windows DOS Prompt console.
Let me know if you have found a solution.