Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!prcrs!john From: john@prcrs.UUCP (John C. Schettino Jr.) Newsgroups: comp.unix.wizards Subject: Re: Apparent bug in fclose()-exec()-freopen() sequence Summary: using fork/exec and stdin, stdout, stderr Message-ID: <111@prcrs.UUCP> Date: 19 Jun 89 12:19:41 GMT References: <20032@adm.BRL.MIL> Organization: PRC Realty Systems, McLean, VA Lines: 52 In article <20032@adm.BRL.MIL>, keith@fstohp.crd.ge.com (Keith D Gregory) writes: > > In short, if one attempts to fclose() files, exec() another program, > and freopen() the same files, the freopen() appears to fail. In the .... > #include > > void main() > { > fclose( stdin ); > fclose( stdout ); > fclose( stderr ); > > execl( "p2", "p2", NULL ); > } When you exec a program, that program takes its stdin, stdout, and stderr from the current executable image (this is howe the shell supports redirection.) So in the example above, "p2" is started with stdin, stdout, and stderr closed, ie there are no valid file pointers or file descriptors available. > #include > > void main() > { > if (freopen( "/dev/tty", "w", stderr) == NULL) > exit( -1 ); > else > fprintf( stderr, "Reopened StdErr, Flags = %d, FileNo = %d\n", > stderr->_flag, stderr->_file ); > > fflush( stderr ); > > < ADDITIONAL EXAMPLES REMOVED> > } Ok, so program p2 trys to freopen a closed file pointer. The first thing it does is close a file descriptor which is NOT open. This is "not good", and your behavior is undefined. Your "work around" of leaving the files open is actually correct. Remember that an exec() call starts up an executable which takes many things from the current executable: - open file descriptors (without the close-on-exec flag set, see fcntl) - COPY of the environment - file pointers for stdin, stdout, stderr (and in PC-DOS, stdprn) - current userid, groupid, etc. Hope this helps... --------------------- John Schettino : uunet!prcrs!john [no snappy saying or disclaimer]