Regex en argument

Version imprimable

28/10/2018, 22h25
lokomass

Regex en argument
Bonsoir à tous,

J'ai créer un petit script qui récupère une liste de noms de serveurs, et j'aimerai pouvoir passer un argument en regex pour filtrer la liste.
Exemple, du fichier en entrée :
Code:

1 2 3 4 5 dvdsid04 dvdsid05 dv20b01 db20b02
Je tape la commande :

Code:

./my_script.sh ^dvd*

J'aimerai que la sortie soit :
Code:

1 2 3 dvdsid04 dvdsid05
Voici mon code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 while read HOST do # Si la ligne n'est pas vide if [ ! -z "$HOST" ] then # Application de la regex if [[ "$HOST" =~ $1 ]] then echo "$HOST" fi fi done < "$SOL"
Or, la sortie de mon script est :
Code:

1 2 3 4 dvdsid04 dvdsid05 dv20b01
Pourquoi ?
J'aimerai, logiquement avoir tout ce qui commence par dvd.
Merci pour votre aide
28/10/2018, 22h51
N_BaH

Bonjour,

ta regex signifie : toute chaîne qui commence par dv, suivie de zéro, un ou plusieurs d.
28/10/2018, 22h55
CosmoKnacki

Tu confonds la syntaxe des regex avec celle de glob.

dvd* pour glob signifie bien "dvd" suivie de n'importe quoi d'autre, alors que pour une regex il signifie "dv" suivie de la lettre "d" répétée 0 ou x fois.

Donc ta commande devrait être simplement: ./my_script.sh ^dvd
29/10/2018, 00h11
jack-ft
Vous faites comme vous voulez, mais j'ai pris l'habitude de automatiquement et sans réfléchir mettre entre apostrophes les regexp de "grep" et les globs de "find"...
Code:

1 2 echo * | grep 'un.*truc' find dir -name 'un*truc'
car, la plupart du temps, on obtient le même résultat que sans les apostrophes... mais pas toujours:
Code:

1 2 echo * | grep un.*truc find dir -name un*truc
à cause d'expansions non maîtrisées, par exemple si le répertoire courant contient un fichier "un.truc".

Évidemment, on peut/doit mettre des guillemets si la chaîne contient des variables à expanser.
29/10/2018, 10h59
lokomass
Merci pour vos retours,
Du coup la regex n'est peut être pas approprié pour ce que je veux faire...

J'aimerai pouvoir utiliser le caractères *, par exemple :

Fichier d'origine :
Code:

1 2 3 4 5 6 dvdsid04 dvdsid05 dv20b01 db20b02 dvbdd01 dvbdd02
J'aimerai les résultats suivants :
Code:

1 2 3 ./my_script.sh ^dvd* dvdsid04 dvdsid05
Code:

1 2 3 ./my_script.sh *bdd* dvbdd01 dvbdd02
Code:

1 2 3 ./my_script.sh 01$ dv20b01 dvbdd01
Code:

1 2 3 ./my_script.sh 20 (OU ./my_script.sh *20*) dv20b01 db20b02
29/10/2018, 12h39
Flodelarab
Bonjour :coucou:

Si tu continues ton dialogue de sourd, tu ne vas pas progresser.
J'en remets une 4ème couche :

Tu confonds les caractères joker et les expressions rationnelles (=regex) !
- L'interpréteur de commande interprète * et ? comme des caractères joker.
- Les expressions rationnelles/expressions régulières/regular expressions/regex utilisent * ? comme des quantificateurs. (de l'entité placée juste à gauche)
Si tu souhaites utiliser des caractères joker dans le cadre d'une regex, cela ne va pas être possible. C'est l'un ou l'autre.
Ou alors, tu utilises l'occasion de ton script pour trafiquer la formule d'entrée pour transformer '*' en '.*' ,ce qui semble douteux :weird:.
Code:

1 2 3 4 $ filtre='*le*' $ filtre="${filtre//\*/.\*}" $ echo "$filtre" .*le.*
Attention ! Les protections, par simple quotes, ou double quotes, sont, dans ton cas, à vérifier avec minutie.
31/10/2018, 00h52
jack-ft
Citation:

Envoyé par lokomass

Merci pour vos retours,
Du coup la regex n'est peut être pas approprié pour ce que je veux faire...

J'aimerai pouvoir utiliser le caractères *, par exemple :

Tout à fait d'accord avec Flodelarab

Pour clarifier un peu plus, il faudrait que tu comprennes bien la différence.

Soit tu utilises des regexps, soit tu utilises des globs, soit tu inventes un nouveau langage qui va générer probablement une regexp (comme proposé: remplacer "*" par ".*").

Les notations "^" et "$" font partie des regexps.
La notation ".*" fait partie des regexps.

La notation "*" fait partie des globs.

Pour moi, le plus puissant serait d'utiliser les regexps (de base ou générées).

Ensuite, il faut choisir s'il y a un implicite "^" et "$" ou pas.

Du coup, avec implicite "^" et "$" (c'est-à-dire que le script les ajoute à la regexp passée en argument (et éventuellement remplace "*" par ".*")):
Code:

1 2 3 ./my_script.sh 'dvd.*' # commence par "dvd" dvdsid04 dvdsid05
Code:

1 2 3 ./my_script.sh '.*bdd.*' # contient "bdd" dvbdd01 dvbdd02
Code:

1 2 3 ./my_script.sh '.*01' # finit par "01" dv20b01 dvbdd01
Code:

1 2 3 ./my_script.sh '.*20.*' # contient "20" dv20b01 db20b02
Sans implicite "^" et "$" (c'est-à-dire que l'utilisateur doit les mettre s'il les veut):
Code:

1 2 3 ./my_script.sh '^dvd' # commence par "dvd" dvdsid04 dvdsid05
Code:

1 2 3 ./my_script.sh 'bdd' # contient "bdd" dvbdd01 dvbdd02
Code:

1 2 3 ./my_script.sh '01$' # finit par "01" dv20b01 dvbdd01
Code:

1 2 3 ./my_script.sh '20' # contient "20" dv20b01 db20b02
31/10/2018, 00h57
jack-ft
Citation:
Envoyé par Flodelarab

Ou alors, tu utilises l'occasion de ton script pour trafiquer la formule d'entrée pour transformer '*' en '.*' ,ce qui semble douteux :weird:.

Code:

1 2 3 4 $ filtre='*le*' $ filtre="${filtre//\*/.\*}" $ echo "$filtre" .*le.*
Hum... C'est bizarre... :koi:

Chez moi:
Code:

1 2 3 4 5 6 7 8 9 $ filtre='*le*' $ filtre2="${filtre//\*/.\*}" $ echo "$filtre2" .\*le.\* $ filtre3="${filtre//\*/.*}" $ echo "$filtre3" .*le.* $ echo $BASH_VERSION 3.2.57(1)-release

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ filtre='*le*';filtre="${filtre//*/.*}";echo "$filtre"
.*
$ filtre='*le*';filtre="${filtre//\*/.*}";echo "$filtre"                                                                                                                                                                                                        
.*le.*
$ filtre='*le*';filtre="${filtre//\*/.\*}";echo "$filtre"                                                                                                                                                                                                       
.*le.*
$ filtre='*le*';filtre="${filtre//\*/.\\*}";echo "$filtre"                                                                                                                                                                                                      
.\*le.\*
$ filtre='*le*';filtre=${filtre//\*/.\*};echo "$filtre"
.*le.*
$ filtre='*le*';filtre=${filtre//\*/.*};echo "$filtre"
.*le.*
$ echo $BASH_VERSION
4.4.12(1)-release

salut,

le globbing ne fonctionne que sur le système de fichiers et c'est bash qui s'en charge, là il ne s'agit pas de fichiers mais de chaines de caractères dans un fichier

si on tape ./script dv* et que dans le répertoire on a un fichier dvcoincoin on se fait avoir par le globbing, pour éviter ça soit on prend l'habitude de mettre des guillemets simples autour du filtre systématiquement (./script 'dv*'), soit on récupère le filtre en interactif et pas en argument

un truc comme ça fonctionne à priori :
Code:

1 2 3 4 5 6 #!/bin/bash read -p "--> filtre: " filter # on echappe au globbing automatique de bash newfilter=${filter//\?/.?} # on remplace '?' par '.?' newfilter=${newfilter//\*/.*?} # on remplace '*' par '.*?' (non-greedy) echo "--> \"$filter\" transformé en \"$newfilter\"" grep -P "$newfilter" fichier
comme dit plus haut c'est un peu douteux, voire franchement cracra, mais ça fait le job comme attendu :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 $ ./script.bash --> filtre: ^dvd* --> "^dvd*" transformé en "^dvd.*?" dvdsid04 dvdsid05 $ ./script.bash --> filtre: *bdd* --> "*bdd*" transformé en ".*?bdd.*?" dvbdd01 dvbdd02 $ ./script.bash --> filtre: 01$ --> "01$" transformé en "01$" dv20b01 dvbdd01 $ ./script.bash --> filtre: 20 --> "20" transformé en "20" dv20b01 db20b02 $ ./script.bash --> filtre: *20* --> "*20*" transformé en ".*?20.*?" dv20b01 db20b02

Citation:

Envoyé par BufferBob

le globbing ne fonctionne que sur le système de fichiers et c'est bash qui s'en charge, là il ne s'agit pas de fichiers mais de chaines de caractères dans un fichier

Au temps pour moi!
Ça ne va pas être facile d'utiliser le globbing dans ce cas (à moins de créer des fichiers temporaires dehors dans un coin :dehors:)

Citation:

si on tape ./script dv* et que dans le répertoire on a un fichier dvcoincoin on se fait avoir par le globbing, pour éviter ça soit on prend l'habitude de mettre des guillemets simples autour du filtre systématiquement (./script 'dv*'), soit on récupère le filtre en interactif et pas en argument
Citation:
un truc comme ça fonctionne à priori :
Code:

1 2 3 4 5 6 #!/bin/bash read -p "--> filtre: " filter # on echappe au globbing automatique de bash newfilter=${filter//\?/.?} # on remplace '?' par '.?' newfilter=${newfilter//\*/.*?} # on remplace '*' par '.*?' (non-greedy) echo "--> \"$filter\" transformé en \"$newfilter\"" grep -P "$newfilter" fichier
comme dit plus haut c'est un peu douteux, voire franchement cracra, mais ça fait le job comme attendu
Plutôt que "cracra", je dirais que c'est juste un nouveau langage, avec une syntaxe à mi-chemin entre glob et regexp, où certains caractères ont un sens spécial:
- "^" pour début de ligne,
- "$" pour fin de ligne,
- "?" pour un caractère quelconque
- "*" pour une chaine quelconque.

Ça veut dire que pour un usage personnel, c'est bon, mais pour un usage partagé, ce nouveau langage doit être bien documenté.

De plus, il doit être bien spécifié...

[EDIT] (suite à la très juste remarque de Flodelarab):
~~Rq: que se passe-t-il si on passe 'dv[0-9]*b01'? Il y a peu de chances que le script proposé trouve "dv20b01"...~~

Rq: que se passe-t-il si on passe 'dv[0-9]*b01'? Il y a de fortes chances que le script proposé trouve "dv2oops0b01"...

Rq: Peut-être faudrait-il ajouter à ton code newfilter=${newfilter//\./[.]} pour redonner au point "." son statut de caractère normal et éviter que "dvd*.txt" ne matche "dvd3txt" par exemple.

Rq: de manière plus générale, peut-être faudrait-il quoter tous les caractères à l'exception de "^" "$" et faire le traitement spécial pour "?" et "*" afin de traiter les caractères spéciaux d'une regexp (comme "[" "]" "(" ")" etc.), pour que "^dvd[3]" trouve "dvd[3].jpeg" ou afin d'éviter des erreurs sur une saisie comme "^dvd[".

[EDIT] Finalement beaucoup de boulot pour un résultat incertain...

01/11/2018, 14h42
Flodelarab

Citation:

Rq: que se passe-t-il si on passe 'dv[0-9]*b01'? Il y a peu de chances que le script proposé trouve "dv20b01"...

Ben si. Le crochet trouve le 2, et l'étoile le 0.

Mais arrêtez de vous prendre la tête. Je ne vois pas pour quelle obscure raison il réinventerait la roue. Qu'il apprenne les regex, comme tout le monde. Fin.
01/11/2018, 23h53
BufferBob

Citation:

Envoyé par jack-ft

Plutôt que "cracra", je dirais que c'est juste un nouveau langage, (...) ce nouveau langage doit être bien documenté.
(...)
Rq: que se passe-t-il si on passe 'dv[0-9]*b01'? Il y a peu de chances que le script proposé trouve "dv20b01"...

ben c'est justement en ça que je disais que c'est cracra en fait, on ne peut pas utiliser le globbing sur des chaines arbitraires du coup pour satisfaire à la demande du PO on est rendu à s'interfacer entre la syntaxe des regexp et le pseudo-globbing tapé par l'utilisateur.

là je donne un exemple qui tient en 5 lignes, c'est forcément "cracra", la grammaire n'est pas du tout maitrisée (et tu en donnes un exemple parmi pleins d'autres), s'il était question de faire un "nouveau langage" je pense que j'aurais recours à un vrai parser en définissant la grammaire exacte pour ensuite faire la transcription en regex classique (et accessoirement je coderai pas ça en bash).

là on s'en sort avec une astuce, une substitution ou deux, faut plutôt voir ça comme une solution du pauvre qui se contente de satisfaire des consignes permissives/pas assez strictes

Citation:

Envoyé par Flodelarab

Ben si. Le crochet trouve le 2, et l'étoile le 0.

bien vu ;) bon le fait est que jack-ft n'a évidemment pas tort, dv[0-9]*b01 va du coup aussi matcher "dv20_pouet_b01"

Citation:

Envoyé par Flodelarab

Je ne vois pas pour quelle obscure raison il réinventerait la roue.

bof.. ils sont pleins à l'avoir fait, à commencer par les langages de programmation eux-même, y'en a pas deux qui partagent le même moteur d'expressions rationnelles, du coup "ça ressemble... mais c'est pas pareil"

c'est pas un choix que je ferais non plus, et les regex c'est clairement un indispensable quand on programme un tant soit peu, mais qu'on veuille réinventer la roue à l'occasion pour des raisons farfelues ça ne me choque pas (plus?) outre mesure