Closed clonezone closed 7 years ago
Confirmed; b3617f1 is the culprit
This seems pretty bad. I'd like to put out a 2.16 when this gets fixed.
@petdance Should we just revert that commit, release, and work on getting an optimal fix in for 2.18?
Seems like that might be reasonable. I want to get a broken .t written for it first, to verify the broken behavior and then that the reverted commit fixes it.
My thoughts exactly.
There's a test and a fix in the dev branch. @clonezone Would you mind battle testing it a bit before we make a release? I ended up just fixing the problem instead of reverting, because the fix was small and easy.
I can try it on the actual problem situation tomorrow morning.
tack
as of commit 17504aa361eef269c57f43c21e16d1705cd1e7c0 finds the same set of files as does ack standalone v2.12 in the situation that I had a problem with ack standalone v2.14.
@clonezone Thanks for checking! @petdance You wanna do that release tonight?
I'd like to. Let me see what I can do.
So I have a patch for it in #498 , and there's another fix here. Can a fix be released?
Yes, a fix can be released. It's just a matter of me getting time to do so.
@petdance can any assistance be rendered to do a release?
I also just ran into a case where ack ' $'
returned results, but ack -l ' $'
returned nothing.
@petdance : I can also help.
This should be fixed now.
@hoelzro: thanks! Do you know when a new release will be made to CPAN?
@shlomif That's up to @petdance!
@hoelzro : I see. It's been taking him a very long time, unfortunately.
Looks like this went out in 2.16.
Using standalone ack v2.14:
This works fine with standalone ack v2.12.