[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Conditional Regexp matching problem in 3.2
From: |
Chet Ramey |
Subject: |
Re: Conditional Regexp matching problem in 3.2 |
Date: |
Wed, 24 Jan 2007 09:47:58 -0500 |
User-agent: |
Thunderbird 1.5.0.9 (Macintosh/20061207) |
Chet Ramey wrote:
> Kevin F. Quinn wrote:
>> On Tue, 23 Jan 2007 16:55:02 -0500
>> Chet Ramey <chet.ramey@case.edu> wrote:
>>
>>>> I don't get this; I must be missing something. If I do, in
>>>> bash-3.1:
>>> I get identical results with fully-patched versions of bash-3.1 and
>>> bash-3.2:
>> $ /data/g2/tmp/portage/app-shells/bash-3.2_p9-r2/image/bin/bash -version
>> GNU bash, version 3.2.9(1)-release (i686-pc-linux-gnu)
>> Copyright (C) 2005 Free Software Foundation, Inc.
>>
>> $ /data/g2/tmp/portage/app-shells/bash-3.2_p9-r2/image/bin/bash ~/x17
>> yes 1
>> yes 2
>> yes 3
>> yes 4
>>
>> That's with bash-3.2 built with only the 001 through 009 patches
>> applied (we have a few other local patches for various reasons, but I've
>> built without them to be sure they're not affecting this). What's the
>> (7) in the release number - does that refer to difference I might be
>> missing?
>
> Strange. It succeeds on Mac OS X, Solaris, FreeBSD, and BSD/OS. Linux
> fails (Red Hat, FWIW).
The glibc implementation of regcomp/regexec apparently does not allow
backslashes to escape `ordinary' pattern characters. Posix leaves that
behavior undefined; glibc seems to have made a different choice than
most other implementations. It will be complicated to work around.
It's little inconsistencies like this that induce developers to ship their
own versions of library functions.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/