gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Feature suggestion: "tla inventory -0"


From: Tom Lord
Subject: Re: [Gnu-arch-users] Feature suggestion: "tla inventory -0"
Date: Sat, 27 Dec 2003 08:50:56 -0800 (PST)


    > From: Florian Weimer <address@hidden>

    > Tom Lord wrote:

    >> Let's suppose that we want to modify or replace sort, cut,
    >> join, uniq, grep, awk, etc. to handle the extended field syntax
    >> of inventory and tla.  It would be better to remove arbitrary
    >> restrictions on field contents than to replace one set of
    >> arbitrary restrictions with another.

    > But is it going to happen?  I don't think so.  The \0 convention
    > for file names is here to stay for the forseeable future.

I think it is likely to happen.

The biggest obstacle to writing new, usable versions of those programs
is that suitable string, string I/O, and structured data libraries
aren't available yet in the right context.

Such libraries are needed for many reasons, not just those tools.  The
current habbit of using Posix multi-byte routines, UTF-8, and XML
everywhere is too limiting for many applications.  I'm reasonably
confident such libraries will get written for wholly independent
reasons.  (Certainly, every single feature I have in mind for such
libraries has been done in one context or another -- just never all in
one place, in a tight-little coherent package.)

When such a libraries get written there will be a need to tune them
and prove them on tasks for which there is an established practice
with demanding performance expectations.

Meanwhile, all of those standard shell tools have annoying glitches
and inconsistencies in their interfaces, arising out historical
accidents, and turned into requirements by Posix.  Just because the
growth of a few companies in the 1980s managed to freeze unix doesn't
mean it can't be thawed out.

Finally, there's only so many tractable problems around that you can
give out to young, talented programmers to learn on.   As the
libraries come on line, the exercise of writing new versions of those
old tools is one of those problems -- a very good one, in fact.

-t





reply via email to

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