Add -n/--line-number

[petdance]

ack doesn't have a -n/--line-number like grep does. It needs one. Consider backporting it to ack2.

Also figure out what it will be called because -n is already in use for --no-recurse. Or maybe that's a breakage we have in ack 3, and drop -n for --no-recurse, and make -N be --no-recurse.

This needs to get done before ack 3.000.

[petdance]

This will require changing -n from being --no-recurse.

[DabeDotCom]

Re: PR #351

@n1vux wrote:

It is not immediately obvious if this PR addresses the previously discussed issue #311 head-on, or is only approximately the same issue.

I'm pretty sure it's what the OP of that issue was getting at... The biggest difference, of course, being that this includes an (admittedly simple) PR, versus a feature request. «grin»

@petdance wrote:

There is a lot to discuss about this. I don't think it makes sense to have a --no-lineno to force off line numbers without a --lineno to force them on, which is something that people have wanted for a while.

I don't disagree, but I'm a big believer in: "Just 'cuz you can't do everything doesn't mean you can't do anything." And this seemed like the simplest thing that could possibly work. «shrug»

FWIW, my specific use case / impetus was that I was looking for a way to fall back to matching a (?!...) zero-width negative look-ahead assertion with ack — which I can easily install as a regular user into a local::lib — when pcregrep wasn't installed system-wide... But the line numbers were getting in the way.

ack --no-color --no-heading --no-filename --output='$f:$_' got me close, but that prints the filename even when provided with only one filename, which I didn't always want.

Cheers! :-D

[petdance]

I'm going to start a new issue that addresses all this. We need to document the existing behavior, and figure out exactly what new behavior we will have. I'm afraid that just adding a new option is going to have consequences we won't have thought of.

For this problem, code is the least of my concerns right now.