[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why aren't gnu utils normalized?

From: Alan Mackenzie
Subject: Re: why aren't gnu utils normalized?
Date: Sun, 30 Aug 2009 14:13:30 +0000 (UTC)
User-agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE (i386))

Hi, Bob,

Bob Fry <> wrote:
> As a former user of Solaris and sometimes user of Linux or cygwin, I'm
> puzzled by the continued lack of consistency in the options and
> features of commands.  As an example, "join" does not understand a
> numeric field sort.  Surely it would not be difficult to add this as
> an option, but it remains much the way it was decades ago.  

I've never used join, so I'm commenting after glancing at its info page.
Given that you've got to have sorted the files anyway before invoking
join, it seems puzzling that numerically sorted files don't work - at
least the info pages says they won't.

Have you actually tried this?  Does it actually fail to work?  What
happens instead?

To be honest, it sounds more like a bug to me.  At a guess, somebody
reported this in the distant past, and the maintainer "fixed" it by
documenting it.

Can you hack in C?  If so, I suspect this problem would be easy to fix.
Although I haven't looked at the source, I suspect somebody has done
string comparisons on the keys of adjacent records, and used "greater
than" when he really wanted "not equal".

> I understand the desire for continuity but couldn't a new set of
> commands be employed with a flag to use a modern, normalized set of
> options?

What do you mean by "normalized"?

> Gnu commands already have the long version but they seem to mostly do
> the same thing as the old short version.

Yes.  Isn't this the Right Thing?  What would you propose doing instead?

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]