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.