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]

mathieu wrote:

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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Mar 26, 11:11 pm, mathieu <[e-mail]:

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Mar 27, 1:21 pm, Joe Greer <[e-mail]:

(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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Joe Greer]

James Kanze <ja*********@gmail.comwrote in news:9012ef97-63a4-4e52-bdc5-
ea**********@s37g2000prg.googlegroups.com:

On Mar 27, 1:21 pm, Joe Greer <[e-mail]:

>(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.

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.

>

>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.)

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