You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi. I would like to be able to scan for files whose names (not contents) do (or do not) match a regular expression.
Currently, regex-grep does an excellent job of scanning file contents and triggering when a specified pattern is matched. The logic of the scan is found in regex-grep line 42:
An example pattern (to be placed at CUSTOM_OPT_PLACEHOLDER) could be:
[^[:punct:][:alnum:]]
This would trigger if the scan finds anything that's not a common punctuation mark, or alphanumeric. So, this would be caught:
why\ use\ spaces.txt
but this would not:
/path/to/less_weird_filename.txt
The opposite would be nice, too. Here, the change would be to use -v to invert matching so that the scan fails when a filename doesn't match the pattern:
It seems that the most straight-forward route would be to add new tools (e.g., filename-regex-grep or regex-filename-grep or regex-grep-filename) and the negative (e.g., filename-regex-grep-negative, etc.). My concern with that approach would be cluttering up the list of tools with 1..2..4 new tools (suppose someone wanted to use Perl patterns) to accomplish something that's actually fairly trivial.
Another approach could be to create one tool and somehow allow a flag to alter how it runs (e.g., regex-grep-filename with a -v flag). However, that would muddle an otherwise very clean implementation that's inline with the rest of the tools.
Yet another approach would be to parse out of the pattern (e.g., Python allows one to supply (?i) to a pattern to make it case-insensitive; one could look for \(\?[^)]?v[^)]?\)) for an inverse search) but, again, that's muddling the code that's otherwise consistent across the rest of the tools.
Another approach could be to allow one to specify their own "custom" MY_CHECK:
So, sorry about the long-windedness. If you could hit me back with a recommendation as to how you would best like this implemented, I'll be happy to code it up and respond with a PR.
Thanks!
The text was updated successfully, but these errors were encountered:
Hi. I would like to be able to scan for files whose names (not contents) do (or do not) match a regular expression.
Currently,
regex-grep
does an excellent job of scanning file contents and triggering when a specified pattern is matched. The logic of the scan is found in regex-grep line 42:To accomplish the scan I'm looking for, I'm thinking of this for a positive match (trigger if match is found):
An example pattern (to be placed at CUSTOM_OPT_PLACEHOLDER) could be:
This would trigger if the scan finds anything that's not a common punctuation mark, or alphanumeric. So, this would be caught:
why\ use\ spaces.txt
but this would not:
/path/to/less_weird_filename.txt
The opposite would be nice, too. Here, the change would be to use
-v
to invert matching so that the scan fails when a filename doesn't match the pattern:So, long story short, my question to you is:
how would you recommend implementing this?
It seems that the most straight-forward route would be to add new tools (e.g.,
filename-regex-grep
orregex-filename-grep
orregex-grep-filename
) and the negative (e.g.,filename-regex-grep-negative
, etc.). My concern with that approach would be cluttering up the list of tools with 1..2..4 new tools (suppose someone wanted to use Perl patterns) to accomplish something that's actually fairly trivial.Another approach could be to create one tool and somehow allow a flag to alter how it runs (e.g.,
regex-grep-filename
with a-v
flag). However, that would muddle an otherwise very clean implementation that's inline with the rest of the tools.Yet another approach would be to parse out of the pattern (e.g., Python allows one to supply
(?i)
to a pattern to make it case-insensitive; one could look for\(\?[^)]?v[^)]?\))
for an inverse search) but, again, that's muddling the code that's otherwise consistent across the rest of the tools.Another approach could be to allow one to specify their own "custom"
MY_CHECK
:..or read it out the environment:
One could then do something like:
So, sorry about the long-windedness. If you could hit me back with a recommendation as to how you would best like this implemented, I'll be happy to code it up and respond with a PR.
Thanks!
The text was updated successfully, but these errors were encountered: