Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: /dev/null (was Re: Daemonizing question...)
Keywords: daemon, open
Message-ID: <6301@auspex.auspex.com>
Date: 26 Feb 91 19:07:37 GMT
References: <12497@helios.TAMU.EDU> <6276@auspex.auspex.com> <1991Feb26.054518.25282@Think.COM>
Organization: Auspex Systems, Santa Clara
Lines: 26

>While the system doesn't guarantee that /dev/null always exists, it is
>certainly *expected* to exist, and most Unix systems are shipped or
>initially installed with it.  I suspect many Unix systems wouldn't get very
>far without it; I'm sure many vendor-supplied system-management shell
>scripts reference it.

I wasn't saying that all software should be able to run successfully if
"/dev/null" isn't there; I was saying that there's no absolute guarantee
that it's there, and if, for whatever reason, you want your software to
work even if it's not there, your software should be able to cope.

It'd be kind of unpleasant, for example, if you could come up multi-user
if "/dev/null" weren't there, but couldn't log in; you'd have to work a
bit harder to get a shell to let you re-create "/dev/null".  It'd be
even *more* unpleasant if you couldn't even come up single-user....

That *might* have been part of the motivation for using "/" in, say,
"init".  Whether it's worth doing so in *other* daemons is another
question.

(And yes, some other vendor-supplied system-management shell scripts do
reference it.  For example, in one AIX 3.x release, a system-management
shell script references it in an "rm -f" command line, so that the
script will only successfully remove "/dev/null" if it's present. :-))

(That's the system bug to which I referred in my previous posting.)


Brought to you by Super Global Mega Corp .com