Re: bug in hostname

[Bob Proulx]

Paul Jarc wrote:
> A hostname program does not need to talk to the network at all.  The
> kernel keeps exactly one hostname in memory, and the hostname program
> gets/sets it via gethostname()/sethostname().  It's fine to also
> provide access to any names found in DNS, but that isn't central.

Partially agree.  I agree with the first part.  But the -f, --fqdn in
particular must use DNS if the real hostname is not already fully
qualified.  The lack of that functionality is one things that started
a previous thread recently.  If hostname is getting redone then it
would be best to handle this case.

> When it comes to DNS, there can be multiple names, but there need not
> be any "primary" name among them.  There can be, and often is, but
> it's also possible that all may have equal standing.  If all you have
> to start with is an IP address, though, then you're probably only
> going to find one name from there anyway.

This is one of the reasons that personally I prefer setting the
hostname to the fully qualifed domain name.  It just seems cleaner.
There is no ambiguity.  Others disagree and try to do the reverse DNS
mappings to find the fqdn.  But that can be incorrect in a number of
ways as you imply.

> >>   - why some programs expect IP addresses with brackets and some don't?
> 
> Unless both kinds of programs invoke "hostname -i", we don't need to
> care about that.

It would seem to be easier to add the brackets than to remove them.

I personally can't think of any case of a program using 'hostname -i'
which would be correct.  Or that 127.0.0.1 would not always be just as
correct.  What is returned if the machine has multiple network
addresses?  How would returning the first IP address always be correct
in the presence of multiple network devices?  I would deprecate that
option.  Or at least warn against it strongly.

Bob