Skip Menu |

This queue is for tickets about the CPAN-Testers-ParseReport CPAN distribution.

Report information
The Basics
Id: 39459
Status: resolved
Priority: 0/
Queue: CPAN-Testers-ParseReport

People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: "--q qr:..." with capturing
It would be nice if --q qr:... would do something sensible with capturing. My suggestion: if a capture exist in the regexp and there is a match, then output the capture contents instead of the "1". Possible implementation: if the pattern matched and there is a defined and non-empty $1, then output $1, otherwise 1. Regards, Slaven
You said, this was the last, really last and only feature missing? Can you provide four examples where this would be usefule? What do you want when the thing matches multiple times? What if the match itself is the string 0? Just food for thoughts
On Sat Sep 20 15:06:20 2008, ANDK wrote: Show quoted text
> You said, this was the last, really last and only feature missing? > > Can you provide four examples where this would be usefule? > > What do you want when the thing matches multiple times? > > What if the match itself is the string 0? > > Just food for thoughts
I want to have it to see which window managers users use while running the Tk test suite. The window manager is printed out in the first test as the string window manager: FoobarWm So it would be nice if I could write --q 'qr:window manager: (.*)' I don't have any opinion on multiple matches. The matches could be concatenated. But result lines would get even longer as they already might be, so this approach might or might not be useful. As for the string "0", this would not be problematic, because currently the empty string is returned for false. A problem could only arise that the 'empty capture string' and 'not matched' cannot be differentiated. But maybe this problem may be neglected.
Done in 0.0.10. Thanks!