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.