Xref: utzoo comp.unix.questions:9342 comp.bugs.4bsd:1012
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!hp4nl!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.unix.questions,comp.bugs.4bsd
Subject: Re: more unix jokes - /dev/null
Summary: try it
Message-ID: <813@philmds.UUCP>
Date: 21 Sep 88 20:00:53 GMT
References: <8488@smoke.ARPA> <26090@ucbvax.BERKELEY.EDU> <1049@sybase.sybase.com> <1414@star.cs.vu.nl> <811@philmds.UUCP> <8541@smoke.ARPA>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 49

In article <8541@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes:
>In article <811@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
>>>	command > /dev/null
>>    command >&-
>
>But that is not equivalent.  In particular, an error will occur when
>output is attempted to fd#1.

Yes, that would be the result to be expected, wouldn't it? The file
descriptor is closed, and cannot be accessed anymore. However, it seems
like the shell is doing something like redirecting to a /dev/null
device (who can comment on that one?), since the following program
behaved OK (look Ma, no core!):

----------------- s t a r t s   h e r e -----------------
/* iotest */
#include 

main()
{
	int i;

   for (i = 0; i < 3; i++) {
      printf("stdout: %d\n",i); fflush(stdout);
      fprintf(stderr,"stderr: %d\n",i); fflush(stderr); /* not really needed */
   }
}
----------------- e n d s       h e r e -----------------

$ iotest
stdout: 0
stderr: 0
stdout: 1
stderr: 1
stdout: 2
stderr: 2
$ iotest >&-
stderr: 0
stderr: 1
stderr: 2
$ iotest 2>&-
stdout: 0
stdout: 1
stdout: 2
$ iotest >&- 2>&-
$

So to me it seems possible after all...
                                         Leo.