MinGW - Minimalist GNU for Windows

> I don't really know what "tty" does.

Time a brief history (skip below next citation to ignore it)...

tty stands for "TeleTYpe" and dates back to the times when we used
teletypes as terminals/frontends to interact with computers
(teletypes are typewriters connected to a computer).

These teletypes later got replaced by terminals (i.e. CRTs with a
connected keyboard) which for compatibility used the same (basically)
communications protocol as teletypes.

As terminals became more "intelligent" these communications would
be abstracted, made configurable etc. etc.

> The docs say 
[snipped]
> This doesn't mean a lot to me.  Do I want termios?

Don't know. It depends on your program. But I'd assume you want it.

> Should isatty() be returning true if I set this?

Yes.

> Is there a better test of running interactively?

If you are running in a **ix-like shell calling isatty() is a good idea.

Best,
Michael
-- 
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 GPG-keys available on request or at public keyserver

On Tue, 26 Oct 2004 14:16:27 +0200, Michael Gerdau <mgd@...>
wrote :

>> Should isatty() be returning true if I set this?
>
>Yes.
>
>> Is there a better test of running interactively?
>
>If you are running in a **ix-like shell calling isatty() is a good idea.

Since isatty(0) returns 0 in the Cygwin bash shell with the tty option
set, would you say that's a MinGW bug, a Cygwin bug, or an MSVCRT bug?
Is there a reliable test to replace it?

Duncan Murdoch

> >> Should isatty() be returning true if I set this?
> >
> >Yes.
> >
> >> Is there a better test of running interactively?
> >
> >If you are running in a **ix-like shell calling isatty() is a good idea.
>
> Since isatty(0) returns 0 in the Cygwin bash shell with the tty option
> set, would you say that's a MinGW bug, a Cygwin bug, or an MSVCRT bug?
> Is there a reliable test to replace it?

I doubt that MSVCRT and/or WinAPI supply any interactive vs. fake-console type 
of information to the applications. IIRC, in order to run anything on win32 
w/o showing an actual "command prompt" / "DOS window" you have to simulate a 
console anyway, so the app will always think it has one.

A concept of a tty/nontty exists only on cygwin. That's what I make of it.

Cheers, Kuba Ober

On wtorek 26 pa=C5=BAdziernik 2004 12:42 pm, Kuba Ober wrote:
> > >> Should isatty() be returning true if I set this?
> > >
> > >Yes.
> > >
> > >> Is there a better test of running interactively?
> > >
> > >If you are running in a **ix-like shell calling isatty() is a good ide=
a.
> >
> > Since isatty(0) returns 0 in the Cygwin bash shell with the tty option
> > set, would you say that's a MinGW bug, a Cygwin bug, or an MSVCRT bug?
> > Is there a reliable test to replace it?
>
> I doubt that MSVCRT and/or WinAPI supply any interactive vs. fake-console
> type of information to the applications. IIRC, in order to run anything

here anything =3D=3D console subsystem application

Cheers, Kuba Ober

On Tue, 26 Oct 2004 12:42:33 -0400, Kuba Ober <kuba@...>
wrote :

>> >> Should isatty() be returning true if I set this?
>> >
>> >Yes.
>> >
>> >> Is there a better test of running interactively?
>> >
>> >If you are running in a **ix-like shell calling isatty() is a good idea.
>>
>> Since isatty(0) returns 0 in the Cygwin bash shell with the tty option
>> set, would you say that's a MinGW bug, a Cygwin bug, or an MSVCRT bug?
>> Is there a reliable test to replace it?
>
>I doubt that MSVCRT and/or WinAPI supply any interactive vs. fake-console type 
>of information to the applications. IIRC, in order to run anything on win32 
>w/o showing an actual "command prompt" / "DOS window" you have to simulate a 
>console anyway, so the app will always think it has one.
>
>A concept of a tty/nontty exists only on cygwin. That's what I make of it.

I've got a console application that's compiled in MinGW, and I'd like
it to know whether it's getting input that the user types, or
redirected input from a file or pipe.  Isn't there a reliable test for
that?

A little bit more information.  The MSDN help for _isatty says that it
checks whether the handle is a character device.  The help for _stat
says that the st_mode member returned contains flags indicating if
you've got a device or a regular file; I find that the _S_IFCHR flag
is set when isatty(0) works, and is not set when it doesn't.  

Duncan

Hi Duncan,


Duncan Murdoch writes:
> I use a Cygwin bash shell.  Normally I start the shell with the
> CYGWIN variable set using "CYGWIN=binmode tty ntsec".  I noticed
> recently that one of my programs

That is a Mingw program, I guess?  IOW it uses the MS RTL?

> thinks it's running in batch mode rather than interactively, and
> tracked it down to isatty(0) returning false.  If I leave out the
> "tty" from the CYGWIN variable, then isatty(0) returns true.

On Unix, when a program is spawned by a program that wants to act as
an interactive terminal (AKA tty), than that interactive shell uses a
special type of pipe, known as a pseudo-tty (ptty).  One difference
between a regular pipe and a ptty is that with a ptty isatty() will
return 1, while with a regular pipe isatty() will return 0.

Windows doesn't have the concept of a ptty, or rather the mechanism is
called console handle and limited to one specific application, the
console window.  There is no documented way for other applications to
create a pipe that the OS would treat as a console handle.

Cygwin can simulate pttys between applications by using some internal
communication, but that mechanism is limited to Cygwin applications.
Non-Cygwin appliations don't understand the secret handshake (or
whatever Cygwin does) and just see a regular pipe.

I guess that without CYGWIN=tty, bash will connect your program to the
console handles via simple redirection, so your regular Windows
version of isatty() works correctly.  With CYGWIN=tty OTOH, Cygwin
probably will insinuate itself between your program and the console to
control the tty-like behaviour.  In this situation your program
doesn't see the console handle, but a regular pipe instead, so
isatty() returns 0.


benny

Hi Duncan,


See my other post in this thread for background.

Duncan Murdoch writes:
> I've got a console application that's compiled in MinGW, and I'd
> like it to know whether it's getting input that the user types, or
> redirected input from a file or pipe.  Isn't there a reliable test
> for that?

Not really, at least not automatically.  You have to define what
exactly you mean by "getting input that the user types."  Windows only
has the definition "getting input from a console handle or a character
device."  That excludes any terminal emulator other than the standard
console window and a direct connection to it.  It excludes xterm,
Emacs or any program that tries to get between the program and the
console.  Those programs have to use a plain pipe for the connection
and that is not "console handle or a character device."

You can of course manually force the application to fall into
interactive mode, if the application has a command-line option for
that, like e.g. "bash -i".

> A little bit more information.  The MSDN help for _isatty says that
> it checks whether the handle is a character device.

AFAIK, MS's isatty() just uses the Windows API GetFileType() and
reports 1 if that returns FILE_TYPE_CHAR which is documented as "The
specified file is a character file, typically an LPT device or a
console."

> The help for _stat says that the st_mode member returned contains
> flags indicating if you've got a device or a regular file; I find
> that the _S_IFCHR flag is set when isatty(0) works, and is not set
> when it doesn't.

That is just the same information packaged in another form.


benny

Posted on DATE by AUTHOR Duncan Murdoch
> [This may be a duplicate post, but I didn't see the original show up.
> If so, sorry!]
>
> Not sure if this is a MinGW bug, a Cygwin bug, or just the way things
> are, but anyway:
>

I've read all of the posts on this subject to date but responding to the
original anyway.

This issue belongs to Cygiwn if you're using Cygwin distributed shells. 
It is not a bug with isatty().  Read-on.

> I use a Cygwin bash shell.  Normally I start the shell with the CYGWIN
> variable set using "CYGWIN=binmode tty ntsec".  I noticed recently
> that one of my programs thinks it's running in batch mode rather than
> interactively, and tracked it down to isatty(0) returning false.  If I
> leave out the "tty" from the CYGWIN variable, then isatty(0) returns
> true.
>

You don't say if you're using RXVT or not.  Rxvt is known to return isatty
of false.

> I don't really know what "tty" does.  The docs say
>
>>  * `(no)tty' - if set, Cygwin enables extra support (i.e., termios)
>>    for UNIX-like ttys.  It is not compatible with some Windows
>>    programs.  Defaults to not set, in which case the tty is opened in
>>    text mode.  Note that this has been changed such that ^D works as
>>    expected instead of ^Z, and is settable via `stty'.  This option
>>    must be specified before starting a Cygwin shell and it cannot be
>>    changed in the shell.
>
> This doesn't mean a lot to me.  Do I want termios?  Should isatty() be
> returning true if I set this?  Is there a better test of running
> interactively?
>

Good question, I don't have a good example off the top of my head, perhaps
you could use some of the Windows API methods to return the console handle
and if it return an invalid handle determine that there is no console.

Earnie

On Wed, 27 Oct 2004 09:51:43 -0400 (EDT), "Earnie Boyd"
<earnie@...> wrote :

>Posted on DATE by AUTHOR Duncan Murdoch
>> [This may be a duplicate post, but I didn't see the original show up.
>> If so, sorry!]
>>
>> Not sure if this is a MinGW bug, a Cygwin bug, or just the way things
>> are, but anyway:
>>
>
>I've read all of the posts on this subject to date but responding to the
>original anyway.
>
>This issue belongs to Cygiwn if you're using Cygwin distributed shells. 
>It is not a bug with isatty().  Read-on.

Yes, Benny Riefenstahl has convinced me of that.

>> I use a Cygwin bash shell.  Normally I start the shell with the CYGWIN
>> variable set using "CYGWIN=binmode tty ntsec".  I noticed recently
>> that one of my programs thinks it's running in batch mode rather than
>> interactively, and tracked it down to isatty(0) returning false.  If I
>> leave out the "tty" from the CYGWIN variable, then isatty(0) returns
>> true.
>>
>
>You don't say if you're using RXVT or not.  Rxvt is known to return isatty
>of false.

I don't know what Rxvt is, and don't seem to have a man page for it,
so I guess not.

>> I don't really know what "tty" does.  The docs say
>>
>>>  * `(no)tty' - if set, Cygwin enables extra support (i.e., termios)
>>>    for UNIX-like ttys.  It is not compatible with some Windows
>>>    programs.  Defaults to not set, in which case the tty is opened in
>>>    text mode.  Note that this has been changed such that ^D works as
>>>    expected instead of ^Z, and is settable via `stty'.  This option
>>>    must be specified before starting a Cygwin shell and it cannot be
>>>    changed in the shell.
>>
>> This doesn't mean a lot to me.  Do I want termios?  Should isatty() be
>> returning true if I set this?  Is there a better test of running
>> interactively?
>>
>
>Good question, I don't have a good example off the top of my head, perhaps
>you could use some of the Windows API methods to return the console handle
>and if it return an invalid handle determine that there is no console.

What I'm trying to distinguish is between

 echo junk | rterm

and

 rterm

where rterm is a console-mode program, which should operate
interactively in the latter case.  I suspect there will be a console
handle in both cases (but I haven't checked yet).

Duncan Murdoch

Hi Duncan,


Just to clarify what I expect to happen (I haven't tried it):

Duncan Murdoch writes:
> What I'm trying to distinguish is between
>
>  echo junk | rterm

Here isatty(1) (1 ~ stdin) should always return 0, because it's a
pipe.

> and
>
>  rterm

Here isatty(1) will return 1 if you are running directly connected to
a console.

If you are connected to anything else (xterm, Emacs shell buffer,
probably rxvt, and probably Cygwin bash in some configurations),
isatty(1) will return 0, because those programs control your program
via a pipe.  On Unix these programs would use a pseudo-tty instead and
than it would work as we all want.


I think that the key to this issue is that the Windows console uses a
character device for I/O, "CONIN$" / "CONOUT$", see MSDN on the
GetStdHandle() API.

Either somebody will have to figure out how the Windows console uses
those devices and reproduce that mechanism, or somebody will have to
write a new device driver that does a similar thing.  Once this is
done, the mechanism would be usefull in a number of projects.

While searching MSDN, I have stumbled on the
CreateConsoleScreenBuffer() API.  Maybe this is the key to a solution?
Some experimentation will be needed...


benny

> > Since isatty(0) returns 0 in the Cygwin bash shell with the tty option
> > set, would you say that's a MinGW bug, a Cygwin bug, or an MSVCRT bug?
> > Is there a reliable test to replace it?
>
> I doubt that MSVCRT and/or WinAPI supply any interactive vs. fake-console
> type of information to the applications. IIRC, in order to run anything on
> win32 w/o showing an actual "command prompt" / "DOS window" you have to
> simulate a console anyway, so the app will always think it has one.

Obviously, I'm 180 degrees out of phase with reality :) As Benjamin has 
pointed out, typically one doesn't create a console but just a pipe to a 
process, and _isatty() will return 0 on any such redirection. And there's no 
documented way (using the API) to create a console.

So, essentially, anything  (including CygWin) but Windows' own console will 
return 0 from _isatty().

Creating actual consoles is possible if one writes a device driver for that, 
and then still it's rather hackish. I've never seen it work on anything but 
win95. I vaguely recall it being included in the copy of DDK I had at the 
time 95 got released.

Sorry for the confusion.

Cheers, Kuba Ober

Hi Kuba Ober,

Kuba Ober writes:
> And there's no documented way (using the API) to create a console.

To be exact, it's easy to create a console (for use as a client), but
there is no documented API to become a console provider.

benny

> > And there's no documented way (using the API) to create a console.
>
> To be exact, it's easy to create a console (for use as a client), but
> there is no documented API to become a console provider.

That's what I meant :)

Cheers, Kuba

Benjamin Riefenstahl writes:
 > To be exact, it's easy to create a console (for use as a client),

You mean it's easy to create one *unless you already have one*. I.e.,
a process (thread?) can't have several console windows. (Not that I
can think of, off-hand, why one would want to.) Oh well, neither can a
Unix process have several controlling terminals, which is kinda
equivalent.

--tml