Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!intelhf!ichips!inews!pima!bhoughto
From: bhoughto@pima.intel.com (Blair P. Houghton)
Newsgroups: comp.unix.internals
Subject: Re: Redirection of stderr
Message-ID: <3181@inews.intel.com>
Date: 22 Mar 91 03:44:10 GMT
References: <524@bria> <11127@dog.ee.lbl.gov> <536@bria>
Sender: news@inews.intel.com
Distribution: na
Organization: Intel Corp, Chandler, AZ
Lines: 15

In article <536@bria> uunet!bria!mike writes:
>In an article, torek@elf.ee.lbl.gov (Chris Torek) writes:
>>In article <524@bria> uunet!bria!mike writes:
>>>#define fdup2(A,B)	(memcpy(B,A,sizeof(FILE)))	/* UGLY */
>>Not only that, it does not work---because there is no guarantee that
>>a FILE object holds the state. [...]
>works just swimmingly for me, though! :-)

You're lucky, and probably don't close either of them, which
closes both of them, regardless of whether a FILE object holds
the state, because the kernel is now free to unlink the file.

				--Blair
				  "What I need is a real-time,
				   networked, 28 MIPS, tuna melt."