Bug 77531
| Summary: | expr 2.0.12 regex * operator too greedy | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Derek Price <oberon> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | fweimer, twaugh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-11-08 22:32:38 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Derek Price
2002-11-08 17:11:30 UTC
expr sets re_syntax_options to RE_SYNTAX_POSIX_BASIC, which implies RE_DOT_NEWLINE, so I think this is a regex bug. . matches newline just fine: $ expr 'abc > xxxxx > def' : 'abc.*' 13 $ The problem, as near as I can tell, is that when .* matches to the end of the string, it is not backing up again to find if it can find strings that match characters after the * in the pattern: $ expr 'abc > xxxxx > def' : 'abc > .* > def' 0 $ I don't think that this is the complete story, though in the pattern above (the same as I initially reported), notice that .* didn't need to match newline at all since both the string and the pattern had all the necessary newlines in it, but I just discovered that this pattern works as expected: $ expr 'abc > xxxxx > def' : 'abc.*def' 13 $ so something is definately wrong but the problem may be some combination of the above. Perhaps the regex matcher wouldn't back up over newline, causing the matcher to drop out with no match after backing up the match far enough to decide that (I've made the newlines explicit): abc\n .* matched abc\n xxxxx\n just fine, but that the \n def\n left in the pattern didn't match the def\n which was as far as it would back up into the string since it hit a newline? Or some such. P.S. This stymies my CVS development under Linux since I can't run the test suite and it doesn't seem to be an easy task to back up to RH 7.3's glibc 2.2.5 or to move forward to Rawhide's glibc 2.3.1 all by my lonesome. Derek There are likely to be some other programs, possibly even related to security issues (LogWatch?), that are relying on proper regex behavior as well. I attempted to build GNU coreutils (formerly sh-utils, I guess) version 4.5.3 on the advice of its (and sh-utils') maintainer, Jim Meyering, as he was not experienceing this problem. I still experience the bug, lending credence to the hypothesis that this bug is in the glibc regex libraries rather than in expr, and thus the sh-utils package. Seems to work just fine in glibc-2.3.1-{2,5,6}.
Wonder why you cannot upgrade to glibc-2.3.1-5, in rawhide is what will
eventually become 8.0 bugfix errata.
Ah, that's where Rawhide fits in. I actually wasn't sure. My bigest problem was finding and downloading all the relevant packages, but I got them all installed now and sure enough, expr works properly again. Thanks for all the help. Well, rawhide is certainly not defined this way, it can contain anything from very experimental to errata candidate packages. But in this case ATM glibc should be ok (it has not gone through official QA, so if you want that, you need to wait, but otherwise you can try it). Well, I've installed 2.3.1-5 and it works so far. Hopefully it won't intorduce any other problems. If it does, I suppose I can try downgrading to 2.2.5 until the official upgrade release. For now, this lets me work on CVS again. Thanks again. |