barmar@think.com (Barry Margolin) (02/26/91)
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
guy@auspex.auspex.com (Guy Harris) (02/27/91)
>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.)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (02/27/91)
If you ever lose /dev/null, you can always restore it from a backup. (You *do* back up /dev/null often, don't you?) Actually, I'm not joking. The last time I lost /dev/null, I was unable to find its major/minor numbers in the vendor-supplied documentation, so I simply restored it from a backup. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
greywolf@unisoft.UUCP (The Grey Wolf) (03/05/91)
<2974@cirrusl.UUCP> by dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) # If you ever lose /dev/null, you can always restore it from a backup. # (You *do* back up /dev/null often, don't you?) # # Actually, I'm not joking. The last time I lost /dev/null, I was unable # to find its major/minor numbers in the vendor-supplied documentation, # so I simply restored it from a backup. Well, you can look in your local conf.c or config.c file somewhere in /usr(/src)/sys (depending on whether or not you have source), and look in the cdevsw[] array. You can look at /dev/mem and /dev/kmem. Chances are pretty good that the major number for /dev/null is the same as those two; the minor number is (usually) one greater than /dev/kmem. #define SARCASM You can always try atlarge# cd /dev atlarge# sh -x ./MAKEDEV #undef SARCASM /* MAKEDEV is a Berkelefication */ # -- # Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> # UUCP: oliveb!cirrusl!dhesi -- # The days of the computer priesthood are not over. # May they never be. # If it sounds selfish, consider how most companies stay in business.