Evan Hunt wrote:
> > The behavior of nohup was intentionally changed in 5.90, as permitted by
> > POSIX: "If stdin is a terminal, nohup now redirects it from /dev/null to
> > prevent the command from tying up an OpenSSH session after you logout."
>
> That makes sense, but maybe we could bring back the former behavior
> as an option, i.e. "nohup --keeptty" or some such? It seems useful.
Can you provide an example where this would be useful?
The problem is the same if you run the test program with input
redirected from /dev/null.
./a.out
bob
./a.out < /dev/null
no
The gnu coreutils info documentation says:
If standard input is a terminal, it is redirected from `/dev/null'
so that terminal sessions do not mistakenly consider the terminal to
be used by the command. This is a GNU extension; programs intended to
be portable to non-GNU hosts should use `nohup COMMAND
[ARG]... </dev/null' instead.
I think there is also a minor glibc bug because file descriptor zero
is not necessarily the controlling terminal. For example HP-UX checks
all of 0, 1, 2, looking for a possible controlling terminal. But even
that is not enough because a controlling terminal may be on file
descriptor 4 or 40 for example.
Regardless of that I think it would be better if the program calling
getlogin() avoided using it since using the utmp file for this
accounting is often a source of troublesome errors. The login user is
rarely the right answer. Usually the current effective id provided by
getpwuid(geteuid()) would be better. I expect that use of getlogin()
in the original case that motivated this example is actually a bug by
itself.
Bob
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
