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

[Bob Proulx]

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