Pourquoi la commande "find -iregex" fonctionne-t-elle mais pas "find -regex" avec l'indicateur insensible à la casse "(?i)" ?

Pour trouver tous les fichiers, exécutez :

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

Notez que j'utilise l'option -iregex pour faire correspondre l'expression sans tenir compte des majuscules et des minuscules.

Les expressions régulières dans le trou du lapin

Les expressions régulières se présentent sous la forme deux saveurs :

1. Basique (ou obsolète), soutenu à l'origine par ed .
2. Étendue (ou moderne), soutenue par egrep et, lorsqu'il s'agit de spécifier l'option -E option, par find y sed . Les expressions régulières étendues peuvent également être utilisées avec bash lors de l'utilisation du =~ opérateur .

Mais ce n'est pas tout : comme expliqué dans man re_format , la syntaxe des expressions régulières peut être améliorée pour prendre en charge des "fonctionnalités supplémentaires" :

Lorsque le REG_ENHANCED est transmis à l'une des options regcomp() des variantes, des fonctionnalités supplémentaires sont activées

(?i) est un exemple d'une telle caractéristique supplémentaire, appelée option inline qui est disponible pour améliorée uniquement les expressions régulières étendues. Lorsqu'elle est utilisée, la sous-expression qui suit (?i) est apparié insensiblement. Par exemple, étant donné l'expression régulière fu(?i)bar La partie "fu" correspondrait à la casse sensible tandis que "bar" correspondrait à la casse insensible.

Malheureusement, c'est là que les choses deviennent floues, car c'est à la commande que vous utilisez de passer ce drapeau en interne à la commande regcomp() de fonctions et prendre en charge ces fonctionnalités supplémentaires .

Par exemple, egrep prend en charge les fonctionnalités supplémentaires :

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

alors que find ne semble pas les soutenir :

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

Pourquoi vos autres commandes échouent-elles ?

find -E /Volumes/complete -regex "(?i).*frontline.*" tente d'utiliser des expressions régulières améliorées, qui ne sont pas prises en charge par le système find .

find -E /Volumes/complete -regex "\.*frontline.*\i" échappe au premier . ce qui fait du premier caractère de l'expression un caractère littéral . . Cela ne correspondra jamais, car toutes les lignes renvoyées par find commencent par le chemin d'accès que vous avez spécifié, à savoir /Volumes/complete c'est-à-dire que le premier caractère est / , pas . .

find -E /Volumes/SeedDrive/complete -regex "(?i:.*frontline.*)" tente d'utiliser des expressions régulières améliorées, qui ne sont pas prises en charge par le système find .

find -E /Volumes/SeedDrive/complete -regex "(\?i:.*frontline.*)" tente d'utiliser des expressions régulières améliorées, qui ne sont pas prises en charge par le système find .

find /Volumes/SeedDrive/complete -regex "*[fF]rontline.*" Il manque un . au début de l'expression régulière. L'utilisation de guillemets doubles n'est pas en cause.