fileno / isatty on C++ stream

[mathieu]

Hi there,

I am trying to implement a cross platform way of printing colored
strings (tty on unix and CONSOLE_SCREEN_BUFFER_INFO on win32). As far
as I understand there is no way to find out if a C++ stream is
attached to a tty, correct ?

Can I do something like that instead:

int detect(std::istream &is)
{
if( &is == &cout ) return fileno(stdout);
...
}

Thanks
-Mathieu

 

[Victor Bazarov]

I am trying to implement a cross platform way of printing colored
strings (tty on unix and CONSOLE_SCREEN_BUFFER_INFO on win32). As far
as I understand there is no way to find out if a C++ stream is
attached to a tty, correct ?

There is no Standard way to find that out, since there is no 'tty'
in the C++ standard language.

Can I do something like that instead:

int detect(std::istream &is)
{
if( &is == &cout ) return fileno(stdout);
...
}

And what would it buy you? In Windows (as in Unix, most likely)
standard output can be redirected to anything.

V

 

[James Kanze]

I am trying to implement a cross platform way of printing
colored strings (tty on unix and CONSOLE_SCREEN_BUFFER_INFO on
win32). As far as I understand there is no way to find out if
a C++ stream is attached to a tty, correct ?

Nothing portable. Even under Unix, you'd need to 1) determine
that the streambuf of the istream is a filebuf, 2) find the
corresponding fd (most implementations support this as an
extention, but it's not part of the standard), and then call
isatty. And even then, you don't know whether it will support
color, and if so, how to change the colors.

Can I do something like that instead:

int detect(std::istream &is)
{
if( &is == &cout ) return fileno(stdout);
...
}

The if doesn't tell you whether the device is a tty: it could be
a pipe or a file as well. And fileno() isn't a standard
function either; it's a Posix extension.

There might be something in curses which could help. (There is
a version of curses for Windows.) But it may be more than you
want or need.

 

[Joe Greer]

isatty. And even then, you don't know whether it will support
color, and if so, how to change the colors.
....

There might be something in curses which could help. (There is
a version of curses for Windows.) But it may be more than you
want or need.

Assuming you can determine that you are on a tty, then you can use the
termcap/termio libraries to find out the capabilities of your tty based
upon the TERM environment variable. (I'm still amazed that they go through
all this terminal emulation stuff. I haven't seen an actual terminal
connected to a *nix box in ages, yet they still emulate a vt100 or one of
its kin. Go figure, ) With Windows, it's a bit more straight forward
once you determine that you are indeed attached to a console, however that
can be a trick.


joe

 

[James Kanze]

(I'm still amazed that they go through all this terminal
emulation stuff. I haven't seen an actual terminal connected
to a *nix box in ages, yet they still emulate a vt100 or one
of its kin. Go figure, )

It's to be expected, really. The terminal windows (e.g xterm)
emulate a VT-100 because that's the way the existing software
addresses the terminal. And new software continues to address
the terminal like that because that's what the terminal window
supports.

With Windows, it's a bit more straight forward once you
determine that you are indeed attached to a console, however
that can be a trick.

I'm not sure, but aren't there system calls to change the code
page? Which would fail if you aren't in a terminal window.
(Unix has a standard function isatty(), but the way I've always
seen it implemented is to do a ioctl with some terminal specific
operation.)

 

[Joe Greer]

It's to be expected, really. The terminal windows (e.g xterm)
emulate a VT-100 because that's the way the existing software
addresses the terminal. And new software continues to address
the terminal like that because that's what the terminal window
supports.

Yes, I understand that, however, you would think that an X way would have
surfaced that didn't rely on serial terminal emulation. I mean with
standalone GUI editors and even GUI command prompts it would be possible to
do quite a bit more than a terminal would allow.

I'm not sure, but aren't there system calls to change the code
page? Which would fail if you aren't in a terminal window.
(Unix has a standard function isatty(), but the way I've always
seen it implemented is to do a ioctl with some terminal specific
operation.)

Not sure. Since I have never wanted to do this sort of thing on Windows,
so I haven't looked too closely. I do know that consoles don't necessarily
have to be visible and that services, for example, have consoles but things
written to them disappear into the void.

joe