Bruno Haible <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
