Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin
Date: Wed, 05 Dec 2007 12:17:00 -0000	[thread overview]
Message-ID: <20071205101109.GA31968@calimero.vinschen.de> (raw)
In-Reply-To: <4755E78F.7000301@portugalmail.pt>

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
console window.

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/
exec magic.

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.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


  parent reply	other threads:[~2007-12-05 10:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-03 10:02 Pierre Muller
2007-12-04 23:50 ` Pedro Alves
2007-12-05  9:22   ` Pierre Muller
2007-12-05 22:56     ` Pedro Alves
2007-12-05 12:17   ` Corinna Vinschen [this message]
2007-12-05 19:19     ` Eli Zaretskii
2007-12-05 23:01     ` Pedro Alves
2007-12-06  1:06       ` Daniel Jacobowitz
2007-12-06  3:42         ` Pedro Alves
2007-12-06  4:25           ` Pedro Alves
2007-12-06 11:21             ` Corinna Vinschen
2007-12-07 13:54               ` Christopher Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071205101109.GA31968@calimero.vinschen.de \
    --to=vinschen@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox