Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: Redirecting stdout, and then getting it back
Message-ID: <15202@smoke.brl.mil>
Date: 14 Feb 91 22:16:59 GMT
References: <1991Feb14.035930.20173@berlioz.nsc.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 15

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
>  stdout and stderr to files that we could parse/show to the user from within
>  the "shell".  This part works fine.

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
stdin, stdout, and stderr will start out assigned to those file
descriptors, there is no guarantee that the same file descriptors will
be in use for those stdio streams after the freopen()s.

To keep the original file descriptors from being lost by the freopen()s,
you can save the value of dup(fileno(stdio_stream_here)), then later use
dup2() to move them to the original values 0,1,2.