Xref: utzoo comp.unix.wizards:22446 comp.bugs.4bsd:1572 Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!ulysses!ulysses.att.com!smb From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: comp.unix.wizards,comp.bugs.4bsd Subject: Re: How to divorce a process from the controlling tty (was syslogd.c) Message-ID: <13114@ulysses.att.com> Date: 12 Jun 90 19:59:21 GMT References: <1990Jun8.070904.7466@athena.mit.edu> <36447@sequent.UUCP> <11388@pixar.UUCP> Sender: netnews@ulysses.att.com Lines: 34 In article <11388@pixar.UUCP>, bp@pixar.UUCP (Bruce Perens) writes: > > I think the usage of / for this is descended from a version of unix so > old that it did not have /dev/null . I don't believe in programs that > do this "because /dev/null might not exist". I'm not sure in what sense you ``don't believe in'' such programs. They most certainly do exist.... And no, they're not from code that old. I don't know how old /dev/null is, but I assure you it's much older than syslogd. > It might be that the programmer > wants the fd open to something that will cause an error on _write_, but > I don't buy that either. This code would fail if > some system didn't allow one to open / as a regular file, which I feel > is more likely than /dev/null going away, especially in the context of > network filesystems. As I replied earlier by email to Jonathan Kamens, code like that most certainly was intended to deal with /dev/null not being there. And while I don't recall cases of /dev/null going away, I've seen a fair number of instances of /dev/null having the wrong modes, or somehow being replaced by a regular file. There exists a school of thought, among some very serious wizards, that says that / is the only thing you know for certain exists. (Or rather, if it's not there, you're not likely to be able to do much of anything anyway...) The idea is to minimize the vulnerability of the subsystem to other failures. I'm not saying I agree or disagree -- I'm saying that the idea has been propounded, by highly-qualified people. --Steve Bellovin