Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: more unix jokes - /dev/null
Message-ID: <8563@smoke.ARPA>
Date: 22 Sep 88 17:41:44 GMT
References: <8488@smoke.ARPA> <26090@ucbvax.BERKELEY.EDU> <1049@sybase.sybase.com> <813@philmds.UUCP>
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <813@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes:
- 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!):

The program did NOT behave okay.
However, since you did not test your printf/fprintf return status,
you didn't discover that.
More carefully written applications would FAIL when writing to a
closed file descriptor.

The Bourne shell closes the file descriptor for >&- etc.