This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin
On Dec 4 23:49, Pedro Alves wrote:
> #include <stdio.h>
> #include <stdlib.h>
> int main ()
> printf ("isatty 0 = %d\n", isatty (0));
> printf ("isatty 1 = %d\n", isatty (1));
> printf ("isatty 2 = %d\n", isatty (2));
> return 0;
> This GDB was configured as "i686-pc-cygwin"...
> (gdb) r
> Starting program: /home/pedro/isatty/main.exe
> isatty 0 = 0
> isatty 1 = 0
> isatty 2 = 0
> I don't know enough of the Cygwin tty support,
> but I would expect that if gdb had a (Windows) console
> attached (bash started from cmd.exe, not the xterm or rxvt),
> the inferior would inherit it, and the runtime would arrange
> for the isatty to be true, but that doesn't seem to hold.
> Neither CYGWIN=tty nor 'set new-group 0' seemed to help.
> This probably has something to do with starting the inferior
> with CreateProcess in win32-nat.c:win32_create_inferior.
Right. The problem occurs when running a session in a pseudo tty like
when starting GDB in a ssh session or when you set CYGWIN=tty before
starting the first Cygwin process (the shell, usually) in a Windows
Pseudo ttys are implemented in Cygwin using pipes. When you start a
Cygwin application with fork/exec, the knowledge about this pipes (being
a pseudo tty) is inherited by the child process by means of the fork/
If you start a Cygwin process from another application using native
Windows functions (CreateProcess, etc), the whole fork/exec magic is
missing, apparently. One result is that the child process has to
figure out what the stdin/out/err streams are, using native Windows
functions. Since native Windows functions have no idea what a pseudo
tty is, the information returned is that stdio streams are connected
to pipes. So the child thinks its stdio streams are just pipes and
pipes are not ttys, apparently.
Cygwin Project Co-Leader