2

According to the man pages we should be able to use regex with the native find command like so:

find -E /Volumes/complete -regex "(?i).*frontline.*"

However it fails. I have tried quite a few variations which have also failed.

find -E /Volumes/complete -regex "\.*frontline.*\i"
find -E /Volumes/SeedDrive/complete -regex "(?i:.*frontline.*)" 
find: -regex: (?i:.*frontline.*): repetition-operator operand invalid
find -E /Volumes/SeedDrive/complete -regex "(\?i:.*frontline.*)"
find  /Volumes/SeedDrive/complete -regex "*[fF]rontline.*"

Don't understand why but single quotes does work:

find -E /Volumes/SeedDrive/complete -regex '.*[fF]rontline.*'

finds "frontline" or "Frontline"

Problem is I also have files that contain FRONTLINE, Frontline, frontline.

man find says:

The options are as follows:

 -E      Interpret regular expressions followed by -regex and -iregex
         primaries as extended (modern) regular expressions rather than
         basic regular expressions (BRE's).  The re_format(7) manual page
         fully describes both formats.

man re-format says"

Inline Options (available for enhanced extended REs only) Like the inline literal mode mentioned above, other options can be switched on and off for part of a RE. ‘(?o..)’ will turn on the options specified in o.. (one or more options characters; see below), while ‘(?-o..)’ will turn off the specified options, and ‘(?o1..-o2..)’ will turn on the first set of options, and turn off the second set.

 The available options are:

       i      Turning on this option will ignore case during matching, while
              turning off will restore case-sensitive matching.  If
              REG_ICASE was specified to regcomp(), this option can be use
              to turn that off.

...

The scope of the option change begins immediately following the right parenthesis, but up to the end of the enclosing subexpression (if any). Thus, for example, given the RE ‘(fu(?i)bar)baz’, the ‘fu’ portion matches case sensitively, ‘bar’ matches case insensitively, and ‘baz’ matches case sensitively again (since is it outside the scope of the subexpression in which the inline option was specified).

 The inline options syntax can be combined with the non-capturing
 parenthesized subexpression to limit the option scope to just that of the
 subexpression.  Then, for example, ‘fu(?i:bar)baz’ is similar to the
 previous example, except for the parenthesize subexpression around
 ‘fu(?i)bar’ in the previous example.
4
  • 5
    As it says, the inline options are "available for enhanced extended REs only", and find -E only supports regular (non-enhanced) extended REs. The /.../i version didn't work because that's not really RE syntax -- that's the syntax some languages use for surrounding an RE, but not part of the RE itself. The "*[fF]rontline.*" version didn't work because you forgot the "." at the beginning of the RE. Commented Oct 17, 2022 at 7:41
  • I didn't try it, but perhaps adding the option -regextype posix-extended helps. Commented Nov 3, 2022 at 12:06
  • @user1934428 Yes for GNU find (brew install findutils) valid types are ‘findutils-default’, ‘ed’, ‘emacs’, ‘gnu-awk’, ‘grep’, ‘posix-awk’, ‘awk’, ‘posix-basic’, ‘posix-egrep’, ‘egrep’, ‘posix-extended’, ‘posix-minimal-basic’, ‘sed’. MacOS installed find does not have this option.
    – John
    Commented Nov 3, 2022 at 14:40
  • Why don't you install the gnutools on the Mac? Most of them are more handy than the BSD ones, and you can have both of them in parallel, if you are worried of breaking existing scripts. Commented Nov 4, 2022 at 7:17

1 Answer 1

5

To find all files, run:

find /Volumes/SeedDrive/complete -iregex ".*frontline.*"

Note that I'm using the -iregex option to match the expression in a case-insensitive manner.

Down the rabbit hole of regular expressions

Regular expressions come in two flavors:

  1. Basic (or obsolete), originally supported by ed.
  2. Extended (or modern), supported by egrep and, when specifying the -E option, by find and sed. Extended regular expressions can also be used with bash when using the =~ operator.

But there's more: as explained in man re_format, the regular expression syntax can be enhanced to support "additional features":

When the REG_ENHANCED flag is passed to one of the regcomp() variants, additional features are activated

(?i) is an example of such an additional feature, called inline option, which is available for enhanced extended regular expressions only. When used, the subexpression after (?i) is matched insensitively. For example, given the regular expression fu(?i)bar, the "fu" portion would match case sensitively while "bar" would match case insensitively.

Unfortunately, this is where things get blurry, because it's up to the command you use to internally pass that flag to the regcomp() family of functions and support those additional features.

For example, egrep supports the additional features:

$ ls
fuBAR    fubar
$ ls | egrep -E 'fu(?i)bar'
fuBAR
fubar

while find doesn't seem to support them:

$ ls
fuBAR    fubar
$ find -E . -regex '.*fu(\?i)bar'
$

Why do your other commands fail?

find -E /Volumes/complete -regex "(?i).*frontline.*" tries to use enhanced regular expressions, which are not supported by find.

find -E /Volumes/complete -regex "\.*frontline.*\i" escapes the first ., which makes the first character of the expression a literal .. This will never match, because all lines returned by find start with the path you specified, namely /Volumes/complete, that is, the first character is /, not ..

find -E /Volumes/SeedDrive/complete -regex "(?i:.*frontline.*)" tries to use enhanced regular expressions, which are not supported by find.

find -E /Volumes/SeedDrive/complete -regex "(\?i:.*frontline.*)" tries to use enhanced regular expressions, which are not supported by find.

find /Volumes/SeedDrive/complete -regex "*[fF]rontline.*" is missing a . at the beginning of the regular expression. The use of double quotes is not the culprit.

3
  • 1
    I don't think (?i) is an ERE feature, I think it's PCRE.
    – Barmar
    Commented Oct 17, 2022 at 14:29
  • You're right, (?i) is not an ERE feature (but an enhanced ERE feature), and it is definitely a PCRE feature (see pcre.org/current/doc/html/pcre2syntax.html#SEC16). I've expanded my answer to make that clear.
    – jaume
    Commented Oct 17, 2022 at 14:38
  • For posterity.... ENHANCED FEATURES is not available in the current implementation of find apple.stackexchange.com/a/255619/40153
    – John
    Commented Oct 17, 2022 at 19:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .