Add --files alias for -f

[markstos]

Some justifications for adding --files an alias for -f:

1. --files is more readable for scripting
2. --files could be easier to remember. Lot of CLI tools also use -f for "force".
3. For compatibility with rg. Even if you don't user ripgrep directly, it's a favorite choice of AI coding agents, so increasing number of people are seeing rg syntax scroll by, including --files.
4. It's backwards compatible.
5. --files is unlikely to be used for anything other than an anlias
   for -f in the future, so it's likely forward-compatible, too.

(I'm not suggesting adding any /further/ compatible with rg, only that's nice to align new flags with /something/)

[petdance]

Does it make sense to make one for -g as well?

[markstos]

Does it make sense to make one for -g as well?

I call YAGNI here-- rg clearly did by not implementing it at all (rg --files | rg 'PATTERN' works), and I apparently did because I forgot the flag existed. I'd probably also use ack --files | ack 'PATTERN' myself, as I need it rarely I can accomplish the same functionality easily with features I /do/ remember.

So if anything, I'd go the opposite direction with -g and remove it in a future breaking change release.

[petdance]

I don't get why I would remove -g

[markstos]

I don't get why I would remove -g

Because it's rarely used and there's an easy alternative: ack --files | ack 'PATTERN'

But that conversation is out of scope here. The direct question was whether to add a long-files flag for -g.

Personally, I wouldn't because I expect -g is rarely used. Unless there's another newer grep-like tool it would help compatibility with. rg at least doesn't have a flag like that.

[petdance]

Because it's rarely used and there's an easy alternative: ack --files | ack 'PATTERN'

I use -g all the time and I made it because I tired of ack --files | ack 'PATTERN' myself.

I get that rg is different. Compatibility with rg isn't a goal, any more than compatibility with ack is a goal for them.

So I'll just add --files.

[pelagic]

I use -g all the time and I made it because I tired of ack --files | ack 'PATTERN' myself.

I'm also tired of ack -g 'FILEPATTERN' | ack -x 'PATTERN' and using it all the time anyway.
Maybe you could somehow combine this into one option :)

[n1vux]

@pelagic ­— Ack2 actually allowed combining -g pattern [--match] pattern on one command, and it was removed for cause. Experience had proved it to be fraught.

Making --match flag prefix non-optional if -g pattern appears might in theory have been sufficient, but the error messages when a intended pattern is read as a directory name is inscrutable since the user knows what they meant. Also, does -i|-I apply to both patterns or just the --match pattern? Would really need to reverse course and take order into account to resolve -i -g --match sanely.

Explicit separation of ack -g | ack -x [-match] provides value in separating the scopes of any modifiers like -w -i

(Yes I know I can include (?i)\b....\b in a pattern, ugly. I do do it when using the new-ish --and --or , as they construct composite patterns that reject -w which is worth it as I'm not constructing the and/or by hand (as I did in the old Cookbook!).)

[n1vux]

--files is unlikely to be used for anything other than an [alias] for -f

Not exactly true.

ack3 --files 
Option files is ambiguous (files-from, files-with-matches, files-without-matches)
ack3: Invalid option on command line

Someone who remembers only one might reasonably but wrongly expect it to be an abbreviation for any of the existing three. Which is not an argument against aliasing, exactly, but weakens the argument for, slightly.

(FWIW, -x is actually an alias for --files-from=<STDIN>)

[pelagic]

Explicit separation of ack -g | ack -x [-match] provides value in separating the scopes of any modifiers like -w -i

I understand that perfectly!
But I have this automated reflex to automate repetitive things ...

[n1vux]

But I have this automated reflex to automate repetitive things ...

Same!
(I'm actually surprised I haven't yet made an alias for ack3 --pager='less -iRaj10' (finger memory is working fine‽ and relearning to type ack-less would be hard on these old fingers). Wish I'd done it years ago ... )

But in the above -g --match vs -g | -x case, we found with Ack2 that a personal wrapper script would be safer (better user experience wrto ambiguity, error messages) than building it into single invocation of Ack, so it was removed as an allowable combination from Ack3 (breaking changes being fair at major revision number roll-over). I'm not sure if my update to Ack2 Cookbook ever got posted to Ack3 web documentation, but intent was to share my documentation of the workaround. (It's likely in the ../web issues if not on the website, tho' you obviously don't need my hints for beginners.)

I do have a bash script that does equivalent of --match $a --near $b -C$n
ack3 -iC$n --match $a| ack -iC$n --match $b | ack -iC$n --match $a --or $b --pager='less -iR' in order to find $a within $n lines of $b
(but naturally with more logic, defaults, etc; alias written before I discovered i usually wanted -a -j10 on less),
that being an off-label use-case [more suitable for free-text than code] that Andy wouldn't consider adding to this code-specific grep-er.