Re: nohup definition should be changed

[Nick Maclaren]

> I suspect we may be straying from the original point (namely, the
> question whether POSIX should be changed to allow "nohup" to close a
> tty stdin) and are starting to worry about implementation details. ...

No, not at all.  The question is whether it is a good idea to treat
that particular implementation detail as special, and specify it
explicitly.  In particular, why shouldn't the same wording be used
for (a) dups of stdin/stdout/stderr, (b) other terminals, (c) the
controlling terminal (if any) and (d) the process group?

In particular, I pointed out that some 'conforming' versions of
nohup do NOT do what the description says (i.e. "invoke a utility
immune to hangups" or "At the time the named utility is invoked,
the SIGHUP signal shall be set to be ignored.") because they MERELY
fiddle the process mask.  If the utility traps SIGHUP and then
execs to a process that doesn't, a SIGHUP to the process group
will kill the utility.

Is this a breach of POSIX?  If so, why?  If not, what does that
wording mean, if anything?

> '/' must be present on all conforming POSIX systems; it is required by
> XBD 10.1 "The following directories shall exist on conforming
> systems".  '/dev/null' must also be present, along with a few other
> files.

The question isn't whether "/" is present in the system as a whole,
but whether it is visible to the process.  I know that POSIX doesn't
specify chroot, but I don't think that it is forbidden.  Why should
POSIX require a chroot tree to have a ./dev/null?  And, if it doesn't,
why shouldn't an implementation have a delroot function and command?


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  address@hidden
Tel.:  +44 1223 334761    Fax:  +44 1223 334679