Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!nsc!voder!berlioz.nsc.com!nelson
From: nelson@berlioz.nsc.com (Taed Nelson)
Newsgroups: comp.unix.questions
Subject: Re: Redirecting stdout, and then getting it back
Message-ID: <1991Feb15.153858.11538@berlioz.nsc.com>
Date: 15 Feb 91 15:38:58 GMT
References: <1991Feb14.035930.20173@berlioz.nsc.com> <15202@smoke.brl.mil>
Sender: nelson@dtg.nsc.com (Taed Nelson)
Organization: National Semiconductor Corporation
Lines: 21

In article <15202@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <1991Feb14.035930.20173@berlioz.nsc.com> nelson@berlioz.nsc.com (Taed Nelson) writes:
>>We have a "shell" program which executes programs from within it using the
>>  system()/spawn() call.  We wanted to trap these errors, so we freopen()ed
>
>You were lucky.  The UNIX convention is that file descriptors 0, 1, and 2
>are the standard I/O/error hooks.  While in a given stdio-using program

Actually, we weren't "lucky" -- the man page for freopen() says that this
  is a common use of the command.

Thanks for the replies.  What I didn't make clear enough is that we operate
  under both DOS and Unix;  I thought the REAL solution would be applicable
  to both.  Clearly, I forgot about fork() and did not think of using it
  due to the DOS environment.

Our final solution, which works, is to do another freopen() before going
  to the shell which redirects stdout and stderr back to "CON".  I was
  really happy that that little tidbit was not documented in the manual
  (actually, pissed off is a more appropriate adjective).  I wonder how one
  would actually open a file named "CON"?