On 6/28/13 5:08 AM, Paolo Bonzini wrote:
>>> On non-glibc systems they use gnulib's regex implementation, so they're
>>> fine.
>>
>> You presume much. Bash, for instance, doesn't use a regex implementation,
>> especially not gnulib's.
>
> Does that mean you have no way to make sure that [A-Z] is sane on
> non-glibc implementation? I see sh_regmatch uses regcomp/regexec on
> bash 4.2.
Let's take a minute to establish what we're talking about here. Something
like 'ls [a-z]' uses bash's own matching code. It's closer to fnmatch than
a regex implementation. In fact, the bash strmatch and the glibc fnmatch
code share a common ancestor.
The regex calls you see are for the [[ command's =~ operator.
> What about the remaining 99% that doesn't use your own matching code?
> Including the bash 4.2 source I'm looking at?
See above.
Nobody is arguing that changing glibc is not part of the solution. Once
everyone agrees on an acceptable interpretation, we can make all the code
do the right thing. Making glibc implement the agreed-upon interpretation
is one of the steps. There are just more things that have to be done.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
