bin/57089: "w" does not honor the -n option
Brian Somers
brian at Awfulhak.org
Sun Sep 28 10:40:22 PDT 2003
The following reply was made to PR bin/57089; it has been noted by GNATS.
From: Brian Somers <brian at Awfulhak.org>
To: Kirk Strauser <kirk at strauser.com>
Cc: Dima Dorfman <dima at trit.org>, FreeBSD-gnats-submit at FreeBSD.org,
brian at FreeBSD.org
Subject: Re: bin/57089: "w" does not honor the -n option
Date: Sun, 28 Sep 2003 18:37:41 +0100
I think this conversation reduces to the requirement for a new utmp format.
And if we're going that route, we should really look at utmpx. I don't think
anyone's done more than look at it though :*/
On Mon, 22 Sep 2003 18:39:18 -0500, Kirk Strauser <kirk at strauser.com> wrote:
> At 2003-09-22T22:43:00Z, Dima Dorfman <dima at trit.org> writes:
>
> > and it looks like that rationale still applies.
>
> That makes a certain kind of sense, I suppose.
>
> > I've cc'd brian (who made that change) to see whether he has any input on
> > this. The issue is: So, you want to see numeric addresses--but for which
> > family? If a host resolves to a v4 and v6 address, which one should be
> > displayed?
>
> Ideally, you'd see the address of the socket that the user is connecting on.
> For diagnostic purposes, it'd be nice to get a deterministic answer that tty
> p0 is connecting from 10.0.5.128, and tty p1 is connecting from
> 2001:470:1f00:546:2a0:c9ff:fe08:260a .
>
> > Perhaps the programs that write to utmp/wtmp should just avoid writing
> > hostnames? (although this is just a thought--I haven't tried to think
> > through the implications of doing something like that)
>
> Well, I could see that it may be useful to have a "snapshot" of what the
> hostname was at the time the user originally connected - DNS records do
> change, after all - but is there a good reason not to additionally store the
> address?
> --
> Kirk Strauser
>
--
Brian <brian at Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
More information about the freebsd-bugs
mailing list