Re: nohup definition should be changed

[Paul Eggert]

Nick Maclaren <address@hidden> writes:

> 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?

These might all be nice things to add, but I don't know of any
practical solution to all these problems in a POSIX implementation,
whereas we do have a simple practical solution to the all-too-common
case of the nohup + ssh + tty-stdin problem.

Once someone has implemented a more-general solution we can worry
about its effect on the POSIX standard; in the meantime let's do what
we can do easily for this common case.


> 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?

Yes, because POSIX says that nohup must set the SIGHUP signal to be
ignored.  This is clear to me at least.  If it's not clear to your
supplier I suppose you could file a formal interpretation request.


> I know that POSIX doesn't specify chroot, but I don't think that it
> is forbidden.

Yes, the implementation can support chroot, but if an application uses
chroot it's outside the realm of what POSIX specifies, so it's not an
issue here.  (And again, we're straying away from the question of
"nohup" into an implementation detail.)