bug-bash
[Top][All Lists]
Advanced

[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 <address@hidden> 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    address@hidden    http://cnswww.cns.cwru.edu/~chet/




reply via email to

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