Ereignisinformation:-
Urheber: [EMAIL PROTECTED]
Empfänger: [EMAIL PROTECTED], [EMAIL PROTECTED]
Betreff: END SEXTRACKER CODE
WARNUNG: Die empfangene Datei CODE .pif ist mit dem Virus W32/Klez.h@MM
infiziert. Der Dateianhang konnte nicht erfolgreich gesäubert werden.
___
Jim Meyering wrote:
It works for me with both glibc-2.2.5 and glibc-2.3.1.
If your problem is due to libc having a broken version of regex,
you might be able to get a working version by building
the coreutils with `./configure --with-included-regex'.
Thanks for the help. glibc 2.2.93, at le
Larry Jones wrote:
Derek Robert Price writes:
The expr, version 2.0.12, which happens to be distributed with RH Linux
8.0 is broken. .* is way too greedy. Here's a test case:
FWIW, the oldest 2.0.x I can find is 2.0.13 and it seems to work
correctly, so I'm guessing the bug didn't las
> [oberon@empress coreutils-4.5.3]$ src/expr 'abc
> x
> def' : 'abc
> > .*
> > def'
> 0
>
> RedHat is blaming glibc version 2.2.93. What version of glibc do you
> have installed?
>
> I ask because I'm trying to figure out if this is worth the hassle of
> upgrading glibc without RedHat's help
Derek Robert Price writes:
>
> The expr, version 2.0.12, which happens to be distributed with RH Linux
> 8.0 is broken. .* is way too greedy. Here's a test case:
FWIW, the oldest 2.0.x I can find is 2.0.13 and it seems to work
correctly, so I'm guessing the bug didn't last long. RH just picke
Jim Meyering wrote:
Derek Robert Price <[EMAIL PROTECTED]> wrote:
The expr, version 2.0.12, which happens to be distributed with RH
Linux 8.0 is broken. .* is way too greedy. Here's a test case:
Hi Derek,
Thanks for the report.
I get the expected (not buggy) results when
using the lat
Derek Robert Price writes:
>
> Seems to me an "I'm waiting to upgrade to a write lock" lock would work
> just as well. Such a lock could prevent the creation of any other locks
> and other readers waiting for an upgrade could release their read locks
> in preference of the first server with an
Derek Robert Price writes:
>
> What happens right now if two tag readers are trying to upgrade to
> write-locks at the same time? Can they both have a read lock in the
> same directory and thus each prevent the other from upgrading to a
> write-lock?
Right now, that code has been replaced due
Larry Jones wrote:
Derek Robert Price writes:
What happens right now if two tag readers are trying to upgrade to
write-locks at the same time? Can they both have a read lock in the
same directory and thus each prevent the other from upgrading to a
write-lock?
Right now, that code has
Larry,
What happens right now if two tag readers are trying to upgrade to
write-locks at the same time? Can they both have a read lock in the
same directory and thus each prevent the other from upgrading to a
write-lock?
Derek
--
*8^)
Email: [EMAIL PROTECTED]
Get CVS support
Derek Robert Price <[EMAIL PROTECTED]> wrote:
> The expr, version 2.0.12, which happens to be distributed with RH
> Linux 8.0 is broken. .* is way too greedy. Here's a test case:
Hi Derek,
Thanks for the report.
I get the expected (not buggy) results when
using the latest test release:
ftp:/
The expr, version 2.0.12, which happens to be distributed with RH Linux
8.0 is broken. .* is way too greedy. Here's a test case:
How reproducible:
Always
Steps to Reproduce:
$ expr 'abc
x
def' : 'abc
.*
def'
Actual Results: 0
Expected Results: 13
You can confirm the expected results
12 matches
Mail list logo
