Nick Maclaren <[EMAIL PROTECTED]> 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.) _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
