cvs commit: src/contrib/one-true-awk - Imported sources

[Tim Robbins]

On Tue, May 17, 2005 at 10:59:37AM +0300, Ruslan Ermilov wrote:
> On Tue, May 17, 2005 at 09:53:42AM +0400, Andrey Chernov wrote:
> > On Tue, May 17, 2005 at 08:38:39AM +0300, Ruslan Ermilov wrote:
> > > > We should commit either your or his variant. Awk the only thing left in 
> > > > the base system which not honors collating here and awk's author 
> > > > constantly decline or ignore our patches.
> > > > 
> > > Our locale patches, to be politically correct.  :-)
> > 
> > It is clear from the context.
> > 
> > BTW, why not now? If you fear taking files off the branch, we can avoid 
> > this. Just place the patch to the building directory and apply it at 
> > 'make beforedepend' stage.
> > 
> OK, I will do it (after I hear something from Tim).

My patches were designed to show that one-true-awk could be made to use
the <regex.h> interface fairly easily, automatically gaining support for
locale-sensitive collating in [a-z] bracket expressions, multibyte
characters, etc., but it was never quite ready for "prime time".

The issues that needed to be sorted out were:
(1) how to ensure patches would be accepted upstream, or otherwise, how to
minimize local diffs. (It's almost as simple as replacing "b.c" with a
reimplementation built in <regex.h>, but there are a few places where the
internals of "struct fa" are accessed.)
(2) how to deal with the differences between historic awk REs, POSIX awk REs,
and POSIX BREs. (From memory, this is mostly handled by my patch already.)
(3) what to do about the libc regex routines being slower than the old
awk routines in some cases.

For now, I'd suggest committing the simpler patches to use the locale's
collating order in [a-z] bracket expressions. When I have time, I'll try
to come up with a new version of my patch to make awk use libc regex routines
that better addresses the issues I mentioned above.


Tim