Re: bug in hostname

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> I've begun looking through these and like what I've seen.
>> However, I'd prefer to avoid providing short-named options
>> for --help and --version.
>
> As you like. I did this for compatibility with the Linux /bin/hostname.
> I don't know how important these short options are in practice.

I prefer to avoid adding new short options, unless absolutely necessary,
just in case some other implementation (or even standard) turns up that
uses them for some other purpose.

> But OTOH, I didn't follow compatibility with Linux /bin/hostname in two
> points:
>   - When the machine has multiple long names (i.e. some aliases),
>     my "hostname -f" prints them all, one per line. Linux "/bin/hostname -f"
>     prints only the first one, but has an extra option "-a":
>     "/bin/hostname -a" prints the names except the first one, all in one
>     line, each followed by a space.
>   - "hostname -i" surrounds the IP address with brackets in my implementation,
>     whereas it does not in the Linux /bin/hostname.
>
>> If we really want to fail for -s, -f, or -i when setting the hostname,
>> then it's best to give an additional diagnostic saying why.
>> But wouldn't it be better just to warn or ignore altogether?
>
> I'm not a follower of the "garbage in, garbage out" principle. If some
> options are clearly contradictory, it's better to point the human user to
> his mistake than to do a random action that fits with one part of the
> command line arguments but not with the other part. Especially if the
> action is a destructive one, like setting a hostname or removing a file.

You make a good case.
Setting a hostname is pretty important.
I'll add a diagnostic saying why it fails.
Thanks.