Replacing -G in ack 2.0

[Andy Lester]

Two points in this mail:

* The -G is going away in ack 2.0.  It was a mistake to have two regexes passed to ack.

* What mechanic do we replace it with?

I'm removing -G in ack 2.0 because having more than one regex in an ack invocation is a bad thing.

When ack first started, there was no -f, no -g, no -G.  ack would just take "ack regex", and ack would search for "regex".

Then I added -f to show what files were being searched.  This let us say "ack -f" without a regex.  It was handy.

Then I found myself doing "ack -f | ack regex" to find files that matched a given regex.  So we added "ack -g regex" as a shortcut to do that.  The flags that modify the regex like -w and -i worked with the regex when we were in -g mode.  

And everything was good.

And then I added the -G flag. "ack -G fileregex contentregex" was equivalent to "ack contentregex $(ack -f fileregex)".  Now we have confusion from two regexes in the same ack invocation.  Which does -i modify? Which one does -w modify?  What about inverting with -v?

So I'm making a design decision.  ack 2.0 will only take a single regex anywhere in its invocation.  That means -G has to go away.

That leaves a vacuum because ack -G is very handy.  It's good to be able to say "ack -G core sales" to find "sales" in every file matching "core".

One way to do this is "ack sales $(ack -f core)".  That works so long as "ack -f core" doesn't return more files than your shell can handle.

Another way is "ack -f core | xargs ack sales".  That's a bit more typing.  It also only works if you have xargs, which Windows people don't.

So here's my idea.  We have a -x switch that says "take my files to read from stdin like xargs does".  That way the invocation would be "ack -f core | ack -x sales".  That's a little bit longer than "ack -G core sales", but not much.

ack -G core sales

ack -f core | ack -x sales

This gives us the unambiguous flexibility to have 

ack -f -i core | ack -x sales -w

where that would not be possible with

ack -G core -i sales -w

So, I welcome your feedback on the -x flag.  Does that seem like a viable solution?  Should -x have to take a filename, and then we use -x- to mean "read from stdin"?  Should the long version be --xargs to make it explicitly clear what it means?

Thanks,

xoxo,

Andy

--
Andy Lester => an...@petdance.com => www.petdance.com => AIM:petdance

[Bill Ricker]

Supporting xargs input (as well as output) is an excellent idea and should be done, allowing ack to be either source or sink on an xargs-style pipe. Brilliant. I love it.  (note that -0 handling on input required.)

But that only gets us back to the old double invocation. I don't want to lose -G and -g *functionality* ; I agree that how they are in ack 1.x today is unsatisfactory, but i question the solution of slaughtering them, of tossing the baby out with the bath. Perhaps they can be replaced so we can have a better interface that is richer and still easy.  (Please consider the following brainstorming not criticism.)

Since we're breaking backward compatibility, we need not assume -i's existence means we shouldn't have two regexs as otherwise one must be neutered; we can find a third way . 

Having two *can* be handled far better than ack 1.x does, with freedom to change the flags.  

Even Ack 1.x isn't totally terrible as the cognoscenti can use -G '(?i-sxm)regex' today to get -i on the second regex that comes first, it's just ugly and asymmetrical. But matches how the main regex has to handle /x modifier today. Perhaps both can be better. 

An option to support two regexes well is to allow /ixsm modifiers on the -G or -g flag. Syntax could be 

    -Gisxm 'regex' 

or 

    -G'regex'isxm      -G{regex}isxm      -G/regex/isxm

(but those need additional shell quotes to protect them)

This suggests allowing the 'main' match regex be *optionally* prefixed by (say) -M (for Match) to indicate flags as

    -Misxm 'regex' #case 1 above  

    -M/regex/isxm # case 2 above 

for symmetry

'submitted for your consideration'

--
Bill
@n1vux bill....@gmail.com

[Andy Lester]

But that only gets us back to the old double invocation. I don't want to lose -G and -g *functionality* ;

We're not getting rid of -g, only -G.

ack -g is staying, because that uses one regex.  ack -G is going, because it requires two.

An option to support two regexes well is to allow /ixsm modifiers on the -G or -g flag. Syntax could be 

    -Gisxm 'regex' 

or 

    -G'regex'isxm      -G{regex}isxm      -G/regex/isxm

(but those need additional shell quotes to protect them)

This is all complexity that I'm eliminating.  Trying to wedge two regexes into a single invocation of ack makes everything too complex.

The only benefit of having -G is to save piping output from ack -g into ack.

The following switches all apply to a given regex: -w, -i, -v, -Q, --smart-case.  That's five switches that would have to somehow be doubled up.  The cost in complexity is too high.

This suggests allowing the 'main' match regex be *optionally* prefixed by (say) -M (for Match) to indicate flags as

We already have --match=regex to explicitly specify a regex.

xoa