Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.internals
Subject: /dev/null (was Re: Daemonizing question...)
Keywords: daemon, open
Message-ID: <1991Feb26.054518.25282@Think.COM>
Date: 26 Feb 91 05:45:18 GMT
References: <12459@helios.TAMU.EDU> <12497@helios.TAMU.EDU> <6276@auspex.auspex.com>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 28

In article <6276@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>Apparently when the daemonizing code was written "/dev/null" (a more
>>likely candidate) was not gauranteed to exist under all flavors of
>>Unix (may still not for all I know ;-).
>
>It's not *guaranteed* to exist under *any* flavor of UNIX; somebody
>could have removed it, for example (see "comp.unix.aix", I think, for an
>example of a system bug that blows it away).
>
>It's *likely* to exist under all flavors of UNIX, including 4.xBSD,
>whence that daemonizing code came. 

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.

By a similar token, the system doesn't *guarantee* that /dev/kmem,
/dev/tty, /vmunix (or whatever the standard name for your kernel is),
/etc/rc, or /bin/login exist.  But they had better exist for the system to
run properly.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar


Brought to you by Super Global Mega Corp .com