Basically this would just entail setting the title.keyword filter to either be '.*\\.(js|css)' (the current default) or whatever was passed as the --title option. Should be pretty simple.

While I can understand the motivation for creating this task, I'm pretty wary of continuing to extend and enhance mwgrep. It seems particularly wrong for the Community Tech team to be working on this, given that mwgrep is exclusively used by shell users. Instead of working on a tool that 99.99% of users can't use, the Community Tech team could work on:

• T71489: Expose mwgrep functionality on-wiki
• T88247: insource should search article text on non-wikitext pages. Probably.
• T109715: Replicate production elasticsearch indices to labs

Special:Search already supports an intitle: option, by the way: https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=intitle%3A%22Barack+Obama%22&fulltext=Search. If intitle: can't do an exact title match (and there's not another keyword that can), enhancing intitle: to support regex, for example, would be another better use of Community Tech resources, in my opinion.

I agree that we (Wikimedia engineers) should be working towards making mwgrep mostly obsolete (as far as public wikis are concerned) and that we shouldn't be expanding it's capabilities at the moment. When I want to do stuff like this, I take a copy into my home directory and alter it there, because otherwise I need to write a patch for the puppet repository etc.

@MZMcBride: Good point. If mwgrep were available to the community, they would be able to keep a better eye on on-wiki JS and CSS across all the projects (and then wouldn't have to ask Community Tech to do tasks like T110149). I took a look at the bugs you mentioned:

• T71489: Expose mwgrep functionality on-wiki
  • I think there's little chance this one will happen, as T109715 would be a better solution for several reasons: it gives a lot more flexibility to users, it doesn't have to be as performant, and it makes more sense (since this feature isn't of much use to most 3rd party MediaWiki users).
• T88247: insource should search article text on non-wikitext pages. Probably.
  • Looks like a valid bug, but not high priority. This would definitely be in the domain of the Search team though and not Community Tech.
• T109715: Replicate production elasticsearch indices to labs
  • This would be hugely useful (both to the community and Community Tech). It looks like Yuvi is making good progress on it. I'll ask him if Community Tech can help beta test it or if there's anything else we can do to help move it along.

In the meantime, I do still think this bug would be a useful feature to add to mwgrep and considering it would only be a small code change (2 or 3 lines), I don't think it would consume undue resources from any team. The alternative (in order to resolve T115681) is for us to write a bot or our own shell script (per Krenair). Writing a bot would be hugely inefficient, so I guess creating our own copy of mwgrep would be the next logical alternative. Personally, though, I would prefer to share useful code with other devs, even if it is only shell users for the time being. The up-side is that once T109715 is complete, hopefully it could be reused by anyone on Tool Labs.