Re: cannot compile xcolors under Linux with native X11

[Aleksey Cheusov <cheusov%tut.by@localhost>]

> On Tue, May 02, 2006 at 02:19:10PM +0300, Aleksey Cheusov wrote:
 >> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 >> > 0 x11-links>bmake install
 >> ...
 >> > awk: run time error: regular expression compile failed (Invalid content 
 >> > of \{\})
 >> > \${LOWER_VENDOR}
 >> >         FILENAME="-" FNR=1 NR=1
 >> 
 >> See PR #33410.

> Idiotic GNU.
This was not GNU. This was a patched version of mawk.
Patch causes mawk to use external regexp library
(GNU libc in my case). Patch is my own and it works for me for months.

Another example:

0 g++>/usr/pkg/heirloom/bin/posix2001/awk '/\${LOWER_VENDOR}/'
awk: error in RE `\${LOWER_VENDOR}': invalid '\{ \}' or '{ }'
awk: source line number 1
 context is
         >>> /\${LOWER_VENDOR}/ <<< 

2 g++>/usr/pkg/heirloom/bin/posix2001/awk '/[$][{]LOWER_VENDOR[}]/'
match this ${LOWER_VENDOR}
match this ${LOWER_VENDOR}
^D
cheusov@chen>
0 g++>

> No, we can't implement extended RE as almost anyone else
> does. POSIX was so nice to reduce the standard once more to the minimal
> consent...
Why? NetBSD version of regcomp/regexec works perfectly with {m,n}.

#include <sys/types.h>
#include <regex.h>
#include <stdlib.h>

int main ()
{
        regex_t re;
        if (regcomp (&re, "^a{3,4}$", REG_EXTENDED | REG_NOSUB))
                return 10;
        if (!regexec (&re, "a", 0, NULL, 0))
                return 21;
        if (!regexec (&re, "aa", 0, NULL, 0))
                return 22;
        if (regexec (&re, "aaa", 0, NULL, 0))
                return 23;
        if (regexec (&re, "aaaa", 0, NULL, 0))
                return 24;
        if (!regexec (&re, "aaaaa", 0, NULL, 0))
                return 25;

        return 0;
}

> About the patch, it is still not perfect...
Hm. Where is a problem?

-- 
Best regards, Aleksey Cheusov.