"Bradd W. Szonye" <bradds@concentric.net> writes:

|>  Tom Bjorkholm wrote in message ...
|>  >If you want to read from (or write to) the current terminal,
|>  >[even if the standard streams are redirected] you should
|>  >[open "/dev/tty"] ...
|>
|>  Or in other words, if you want to be sure to read or write from the "real"
|>  terminal even if the standard streams are redirected, you need to rely on
|>  some system-dependent magic. Of course, you can encapsulate the magic in its
|>  own class: perhaps a "termstream" and "termbuf" derived from ostream and
|>  streambuf.

Precisely.  I'm not even sure you can do it on some systems.

In practice, most of the time when you want to input from the keyboard
(regardless of redirections), you also want to do special things like
turning off echo, which are also system dependant.  I've got a Console
class in my things to do list; maybe it should use the streambuf
interface.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

|>  Steve Clamage wrote:
|>  >
|>  > Second, you are mixing levels of abstraction.
|>  >
|>  > Neither C nor C++ has the concept of a console. They have the concept
|>  > of three predefined text streams connected to standard input, output
|>  > and error, but never say what those are.
|>
|>  Well, these standard streams have some generally accepted semantics. When
|>  writing a filter, stdin and stdout are the main input and output from the
|>  program, while stderr is for status or error messages to be shown where the
|>  user can see them. I think accepting direct input from the user from within a
|>  filter is about as reasonable thing to want to do as providing direct output to
|>  the user, so it seems odd to me that the latter can be done portably but not
|>  the former. Obviously, in situations where these standard streams are not
|>  meaningful (i.e., in a Windows program), the programmer won't be using them
|>  anyway.

Except that "providing direct output" to the user is not guaranteed in
any way.  If I look at the processes currently running on my system, for
example, over half are not connected to any interactive device, in any
way.  Off hand, I don't know where their cerr (or stderr) goes, but it
is certainly not to the screen.  Or at least, I don't think so.  Most
of these processes are well behaved, know that they are running as a
system process, and don't output to stderr anyway.

Just curious, but are there any Unix based C++'s where cerr will detect
when the process is not connected to a real device, and switch to a
syslog_streambuf.  For that matter, are there any that even have a
syslog_streambuf, or some equivalent.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

On 10 Dec 97 02:10:23 GMT, "Paul D. DeRocco" <pderocco@ix.netcom.com>
wrote:

>Steve Clamage wrote:
>>
>> Second, you are mixing levels of abstraction.
>>
>> Neither C nor C++ has the concept of a console. They have the concept
>> of three predefined text streams connected to standard input, output
>> and error, but never say what those are.
>
>Well, these standard streams have some generally accepted semantics. When
>writing a filter, stdin and stdout are the main input and output from the
>program, while stderr is for status or error messages to be shown where the
>user can see them. I think accepting direct input from the user from within a
>filter is about as reasonable thing to want to do as providing direct output to
>the user, so it seems odd to me that the latter can be done portably but not
>the former.

You are still making unwarranted assumptions. Nowhere does the C or
C++ standard discuss "status or error messages to be shown where the
user can see them". You have no assurance in C or C++ about where
output directed to the standard error stream actually goes. Trivial
example: on some systems you can redirect it to the null device,
meaning output is discarded without anyone having the opportunity to
see it.

C and C++ allow no portable assumptions about I/O with respect to the
"user" of the program. There need not even be a "user", much less
anything resembling a console.

You could argue that the languages ought to support such notions, but
historically and at present they do not.

In some particular environment -- such as MS Windows, MacOS, or Unix
-- additional rules about I/O and consoles might apply.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

References: <34980577.3473295@engnews1.eng>

Steve Clamage wrote:
>>> Second, you are mixing levels of abstraction.
>>> Neither C nor C++ has the concept of a console. They have the concept
>>> of three predefined text streams connected to standard input, output
>>> and error, but never say what those are.

"Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
>> Well, these standard streams have some generally accepted semantics. When
>> writing a filter, stdin and stdout are the main input and output from the
>> program, while stderr is for status or error messages to be shown where the
>> user can see them. I think accepting direct input from the user from within a
>> filter is about as reasonable thing to want to do as providing direct
output >> to
>> the user, so it seems odd to me that the latter can be done portably but not
>> the former.

stephen.clamage_nospam@eng.Sun.COM (Steve Clamage) then wrote:
> You are still making unwarranted assumptions. Nowhere does the C or
> C++ standard discuss "status or error messages to be shown where the
> user can see them". You have no assurance in C or C++ about where
> output directed to the standard error stream actually goes. Trivial
> example: on some systems you can redirect it to the null device,
> meaning output is discarded without anyone having the opportunity to
> see it.
>
> C and C++ allow no portable assumptions about I/O with respect to the
> "user" of the program. There need not even be a "user", much less
> anything resembling a console.
>
> You could argue that the languages ought to support such notions, but
> historically and at present they do not.
>
> In some particular environment -- such as MS Windows, MacOS, or Unix
> -- additional rules about I/O and consoles might apply.

Don't forget DEC VMS, which has had the following predefined I/O streams
for many years now:
    SYS$INPUT       Standard input
    SYS$OUTPUT      Standard output
    SYS$ERROR       Error output
    SYS$COMMAND     User input

The SYS$COMMAND seems to meet Paul's requirements.  All of these streams
are attached to the user's tty/console by default, but SYS$INPUT and
SYS$OUTPUT can be redirected.  (How SYS$COMMAND is mapped into a C program
running under VMS, I don't know.  Perhaps it's a predefined 'stdcommand'
file stream?)

An example use of such a thing would be a program that processes text file
input (from stdin), producing processed text as output (to stdout), which
also writes warnings and prompting messages for the user (to stderr), and
which requires user input to guide the processing (from stdcommand?).
Such an example is hardly unrealistic.

In general, such an output stream would give programs two complete
bidirectional I/O paths: stdin & stdout, and stdcommand & stderr.
Programs could then be invoked with (say) redirected stdin and stdout but
which could still interact with the user.  All of this presumes some form
of console, true, but on non-interactive systems these streams could still
be given some sort of suitable meaning.  For example, IBM JCL programs
already have //SYSIN, //SYSOUT, and //SYSERR, so presumably they could
also have something like //SYSCMD.  If nothing else, stderr and stdcommand
could be attached to the bit bucket.

FWIW, DOS C implementations usually have stdaux and stdprn which map to
the auxiliary (AUX:) and printer (PRN:) devices, so extensions are known
to exist.  Some C implementations allow reading from stderr, effectively
acting like a stdcommand, but I personally think is a bad way to do it.

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Paul D. DeRocco wrote:
>=20
> Steve Clamage wrote:
> >
> > Second, you are mixing levels of abstraction.
> >
> > Neither C nor C++ has the concept of a console. They have the concept
> > of three predefined text streams connected to standard input, output
> > and error, but never say what those are.
>=20
> Well, these standard streams have some generally accepted semantics. Wh=
en
> writing a filter, stdin and stdout are the main input and output from t=
he
> program, while stderr is for status or error messages to be shown where=
 the
> user can see them. I think accepting direct input from the user from wi=
thin a
> filter is about as reasonable thing to want to do as providing direct o=
utput to
> the user, so it seems odd to me that the latter can be done portably bu=
t not
> the former. Obviously, in situations where these standard streams are n=
ot
> meaningful (i.e., in a Windows program), the programmer won't be using =
them
> anyway.

The Apollo Aegis operating system used to have an error input stream for =
just
this. They threw it out when they went unix compatible.

You probably also want standard-console and standard-graphics streams
(which will only be open if applicable).=20


--=20
Stephen Baynes    MBCS  CEng                Stephen.Baynes@soton.sc.phili=
ps.com
Philips Semiconductors Ltd                 =20
Southampton SO15 0DJ                        +44 (01703) 316431
United Kingdom                              My views are my own.
Do you use ISO8859-1? Yes if you see =A9 as copyright, =F7 as division an=
d =BD as 1/2.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Tom Bjorkholm wrote in message ...
>If you want to read from (or write to) the current terminal,
>[even if the standard streams are redirected] you should
>[open "/dev/tty"] ...

Or in other words, if you want to be sure to read or write from the "real"
terminal even if the standard streams are redirected, you need to rely on
some system-dependent magic. Of course, you can encapsulate the magic in its
own class: perhaps a "termstream" and "termbuf" derived from ostream and
streambuf.
---
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Paul D. DeRocco <pderocco@ix.netcom.com> writes:

> So my question is really this: since the standard provides a portable way of
> writing to the console while standard out is redirected, shouldn't it also
> provide a way of reading from the console while standard in is redirected?
> Otherwise, how would one portably implement something like MORE, that asks for
> a key press while reading its data from stdin?

No one implement more, less or any progran with serious
user interaction in portable C++; some people use curses,
other prefer conio or even TextEdit.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

cerr is an ostream, that on POSIX systems use file descriptor 2.
You cannot read from an ostream.

The POSIX standard defines file handles 0 (standard in), 1 (standard out),
and 2 (standard error). Handle 0 can be used for input, and handles 1 and
2 can be used for output. Reading from handle 2 will result in undefined
behavior.

Note that all three of these file handles (I/O streams in UNIX terminology)
can be redirected (i.e. none of them are guaranteed to use the console).

If you want to read from (or write to) the current terminal, you should
on POSIX systems use:

  //...
  std::fstream fs("/dev/tty");
  fs << "Press return to continue" << std::flush;
  fs >> myVariable;
  //...

This is portable across all POSIX systems. On other systems you will
have to replace "/dev/tty" with some other string.

/Tom

On 6 Dec 1997, Paul D. DeRocco wrote:
>
> Steve Clamage wrote:
> >
> > Neither. cerr is an ostream, not a file stream, and you cannot read
> > from it at all. This has always been the case.
>
> I seem to recall that in C you could read from stderr, but I could be wrong.
> Unless I'm completely out to lunch, in MS-DOS, the standard error handle
> number 2 is both readable and writable.
>
> So my question is really this: since the standard provides a portable way of
> writing to the console while standard out is redirected, shouldn't it also
> provide a way of reading from the console while standard in is redirected?
> Otherwise, how would one portably implement something like MORE, that asks
> for a key press while reading its data from stdin?

--------------------------------------------------------------------------
Tom Bjorkholm  Job: Ericsson Business Networks AB  Home: Serenadv. 36, 3tr
                    Nacka Strand                         131 40 Nacka
C++ and UN*X        131 89 Stockholm, Sweden             Sweden
ISO/IEC FDIS 14882  phone: +46 8 422 1348                +46 8 716 68 94
                    fax:   +46 8 422 2080                +46 8 716 68 94
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

> Steve Clamage wrote:
>
> > Neither. cerr is an ostream, not a file stream, and you cannot
> > read from it at all. This has always been the case.
>
> I seem to recall that in C you could read from stderr, but I could
> be wrong.  Unless I'm completely out to lunch, in MS-DOS, the
> standard error handle number 2 is both readable and writable.

This usually works in Unix as well.  See below.

> So my question is really this: since the standard provides a
> portable way of writing to the console while standard out is
> redirected, shouldn't it also provide a way of reading from the
> console while standard in is redirected?  Otherwise, how would one
> portably implement something like MORE, that asks for a key press
> while reading its data from stdin?

On 06 Dec 97 05:49:55 GMT, "Paul D. DeRocco" <pderocco@ix.netcom.com>
wrote:

>Steve Clamage wrote:
>>
>> Neither. cerr is an ostream, not a file stream, and you cannot read
>> from it at all. This has always been the case.

>I seem to recall that in C you could read from stderr, but I could be wrong.

The C standard in 7.9.3 "Files" defines stderr as a predefined text
stream used for writing diagnostic output. You certainly cannot depend
on being able to read it.

>Unless I'm completely out to lunch, in MS-DOS, the standard error handle number
>2 is both readable and writable.

>So my question is really this: since the standard provides a portable way of
>writing to the console while standard out is redirected, shouldn't it also
>provide a way of reading from the console while standard in is redirected?

First, I am unaware of anything in the standard that provides for
writing to the console at all.

Second, you are mixing levels of abstraction.

Neither C nor C++ has the concept of a console. They have the concept
of three predefined text streams connected to standard input, output
and error, but never say what those are.

Some particular OS might allow reading from an output stream, but that
is a subject separate from what the C and C++ standards say. The
standards address a minimum functionality that one can expect to be
supported on any OS that allows file-like I/O.

Similarly, C and C++ don't address redirection of streams. If they
happend to be redirected, it is outside the purview of the languages.
The standard streams are connected to something, but the language
definitions don't provide for finding out what. Since you don't know
what the streams are connected to, it doesn't make sense (within the
meaning of the standards) to talk about whether they have been
redirected.

>Otherwise, how would one portably implement something like MORE, that asks for
>a key press while reading its data from stdin?

You can make a case that the languages ought to provide for reading
unbuffered keyboard input or detecting a key press, but they do not.
See the FAQ for comp.lang.c or the book "C Programming FAQs" by Steve
Summit for more on that topic.

There are many useful programs which cannot be written entirely in
portable C or C++. You abstract the unportable parts and realize the
abstraction for each platform of interest.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage wrote:
>
> Second, you are mixing levels of abstraction.
>
> Neither C nor C++ has the concept of a console. They have the concept
> of three predefined text streams connected to standard input, output
> and error, but never say what those are.

Well, these standard streams have some generally accepted semantics. When
writing a filter, stdin and stdout are the main input and output from the
program, while stderr is for status or error messages to be shown where the
user can see them. I think accepting direct input from the user from within a
filter is about as reasonable thing to want to do as providing direct output to
the user, so it seems odd to me that the latter can be done portably but not
the former. Obviously, in situations where these standard streams are not
meaningful (i.e., in a Windows program), the programmer won't be using them
anyway.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In the current standard, is cerr an fstream or an ofstream? That is, can one
input from it in order to read from the console while stdin is redirected?

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Paul D. DeRocco <pderocco@ix.netcom.com> schrieb:
> In the current standard, is cerr an fstream or an ofstream? That is, ca=
n one
> input from it in order to read from the console while stdin is redirect=
ed?

  27.3.1  Narrow stream objects              [lib.narrow.stream.objects]

  ostream cerr;

4 The object cerr controls output to a stream buffer associated with the
  object stderr, declared in <cstdio> (_lib.c.files_).

--=20
Claus Andr=E9 F=E4rber <http://www.muc.de/~cfaerber/> Fax: +49-8061-3361
PGP: ID=3D1024/527CADCD FP=3D12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9=
 DC
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 02 Dec 97 16:18:54 GMT, "Paul D. DeRocco" <pderocco@ix.netcom.com>
wrote:

>In the current standard, is cerr an fstream or an ofstream? That is, can one
>input from it in order to read from the console while stdin is redirected?

Neither. cerr is an ostream, not a file stream, and you cannot read
from it at all. This has always been the case.

(Well, in classic iostreams cerr was an ostream_withassign, but that
was still just an ostream.)

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage wrote:
>
> Neither. cerr is an ostream, not a file stream, and you cannot read
> from it at all. This has always been the case.

I seem to recall that in C you could read from stderr, but I could be wrong.
Unless I'm completely out to lunch, in MS-DOS, the standard error handle number
2 is both readable and writable.

So my question is really this: since the standard provides a portable way of
writing to the console while standard out is redirected, shouldn't it also
provide a way of reading from the console while standard in is redirected?
Otherwise, how would one portably implement something like MORE, that asks for
a key press while reading its data from stdin?

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]