Re: why aren't gnu utils normalized?

[Bob Fry]

>>>>> "B" == Barry Margolin <barmar@alum.mit.edu> writes:

Thanks for the followups all.

    B> I think the answer to his general question, then, is that it
    B> would take an enormous amount of work to get all commands to be
    B> consistent this way.

Work, yes, but I don't think enormous. If I weren't an old Fortran
dino I might volunteer, but too many years with that beast gave me
allergies to pointers.

    B> Reconciling all of these, including dealing with some
    B> of the conflicts (especially with traditional single-letter
    B> options) would be a huge undertaking.

Well, I wouldn't touch the traditional single-letter options.
Instead, fix the double-dash options.  Again, I don't think it would
be huge.

    B> Traditionally, the Unix model has been to NOT try to replicate
    B> all these options in every command.  The Unix Way is to have a
    B> toolkit of specialized commands, which can be combined to
    B> produce the results you want.

    B> So if you have two files that are sorted numerically, and want
    B> to join them, you first run them through sort(1) to re-sort
    B> them lexicographically, then run those through join, and
    B> finally sort the result numerically.

Good point.  But as you say in your next para, following that model
dogmatically was too annoying and impractical for actual use, so
commands do duplicate some functionality.

Another poster mentioned broken scripts. Adding the same switch to all
commands (e.g. --unified) would solve that.

Why even think of this?  Because while keeping the current, somewhat
uneven options doesn't bother old-timers, it deters new and occasional
users.  As Linux/Unix gradually becomes more mainstream, inconsistent
options are no longer quaint, merely antiquated.
-- 
We could have saved the Earth but we were too damned cheap.
 ~ Kurt Vonnegut