bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreutils 5.2.1 -> 5.93 regression: With nohup getlogin() returns NU


From: Paul Eggert
Subject: Re: coreutils 5.2.1 -> 5.93 regression: With nohup getlogin() returns NULL
Date: Thu, 22 Mar 2007 09:33:23 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Evan Hunt <address@hidden> writes:

>> Can you provide an example where this would be useful?
>
> When I use nohup, I'm generally either using it as an insurance policy, to
> prevent some lengthy process from getting killed by a flaky network
> bringing down my telnet or ssh session, or else I'm using it to run
> a logging process.
>
> In the former case, I expect the process to behave the same as it would
> any other time, except immune to SIGHUP--even if it calls getlogin(),
> or 'tty', or needs a controlling terminal for some other reason.

If this is the goal, the new nohup option would have to do more than
just affect stdin.  It should also cause nohup to not redirect stdout.

Wouldn't (trap - HUP; command) be simpler?  It would have the desired
effect, and it uses only standard facilities.

> If I'm not mistaken, "nohup sttylog < /dev/ttyXX" wouldn't
> work now; it'd be silently turned into "nohup sttylog < /dev/null".

You're right that it wouldn't work now.  But the transformation isn't
silent; nohup warns "ignoring input".

> (This isn't hard to work around, but then again it isn't hard to add
> a --keeptty option to nohup, either.)

Sure, but if a simple, portable workaround exists, shouldn't we
encourage people to use it rather than go to the effort of supporting
a nonstandard option?  After all, the nonstandard option would require
users to modify their scripts; if they're going to modify them anyway,
they might as well modify them in a portable way, if that portable way
is nearly as simple.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]