Ubuntu-fr

bahcmoa

bash et expressions régulières : grep ... sed ... ???

Bonjour,

Voilà, je m'essaie au script bash (je suis sur Mac) et si j'ai l'habitude de jouer avec les expression régulière en php ou javascript, là j'avoue que je bloque complètement ! ... j'étudie les commandes gred et sed mais il semble qu'elles ne traitent un contenu que ligne par ligne or, moi, je cherche des motifs qui peuvent être sur plusieurs lignes. De plus, il semble que sed ne soit pas insensible à la casse (j'ai essayé avec le flag "I" (i majuscule) et ça me renvoie une erreur me disant que ce flag n'existe pas )

un exemple concret : je récupère le contenu d'un fichier html sur ma machine : index.html, je cherche les liens vers les fichiers css
   

<LINK rel="stylesheet" type="text/css" media="all" href="styles.css" />

... et je veux remplacer ces liens par le contenu des fichier css eux-même pour ensuite injecter le tout dans un nouveau fichier.

Je sais, ce n'est pas très utile mais, j'aime bidouiller, et c'est un exercice comme un autre pour apprendre. Si qu'elqu'un ici aurait quelques pistes à étudier ça serait super ;-) ... du genre, comment faire du multi-ligne avec grep ou sed par exemple ou comment rendre sed insensible à la casse ...

Merci d'avance

pingouinux

Re : bash et expressions régulières : grep ... sed ... ???

Bonjour,

comment rendre sed insensible à la casse

C'est bien I (i majuscle)

$ sed -n '/toto/p' <<<"TOTO"

$ sed -n '/toto/Ip' <<<"TOTO"
TOTO

bahcmoa

Re : bash et expressions régulières : grep ... sed ... ???

merci pingouinux, mais comme je l'ai dit, je suis sur mac, et après quelques recherches, il semble que le flag I (i majuscule) n'existe pas sur mac ... bug ???

sed: 1: "s/\< *[Ll][Ii][Nn][Kk][ ...": bad flag in substitute command: 'I'

bon, j'ai réussi à bricoler un truc (pas très beau mais bon) ... je joue avec les masques [Ll][Ii][Nn][Kk] pour trouver "link"
j'arrive à trouver le nom du fichier css ... mais quand je veux récupérer son contenu ça bloque
en fait, avec mon code il cherche le contenu du fichier 1 et non celui correspondant au masque \1

fichierHTML='index.html'
regexCSS='\< *[Ll][Ii][Nn][Kk][^\>]*href=\"\([^\"]*\)\"[^\>]*\>'
sed -e "s/${regexCSS}/$(cat \1)/g" ${fichierHTML}
# texte trouvé dans mon HTML : <LINK rel="stylesheet" type="text/css" media="all" href="styles.css" />
# il m'isole bien "styles.css"
# mais "$(cat \1)" essaie de lire le contenu du fichier "1" et non "styles.css"
# erreur affichée ==>  cat: 1: No such file or directory

et je bloque toujours sur le multi-ligne si mon tag est sur 2 lignes, le masque ne le trouve pas car sed lit le fichier ligne par ligne apparement

Dernière modification par bahcmoa (Le 26/04/2017, à 17:52)

Watael

Re : bash et expressions régulières : grep ... sed ... ???

salut,

si tu as l'intention de continuer à faire du traitement de fichiers HTML, il est préférable de passer à un langage capable de parser le HTML : python + BeautifulSoup.

Dernière modification par Watael (Le 26/04/2017, à 18:07)

---

Connected \o/
Welcome to sHell. · eval is evil.

Arbiel

Re : bash et expressions régulières : grep ... sed ... ???

Bonsoir

En bash, j'utilise xmlstarlet, mais python est peut-être plus puissant. Je ne connais que bash.

---

Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

pingouinux

Re : bash et expressions régulières : grep ... sed ... ???

Dans ton exemple, pour récupérer le nom du fichier

regexCSS='< *[Ll][Ii][Nn][Kk][^>]*href=\"\([^\"]*\)\"[^>]*>'
sed -e "s/${regexCSS}/\1/g" "${fichierHTML}"

ou s'il y a une substitution de commande

sed -e "s/${regexCSS}/$(echo \\1)/g" "${fichierHTML}"

mais je ne sais pas inclure le cat dans la commande.

Pour info, \< et \> représentent respectivement le début et la fin d'un mot, et non les caractères < et >.

je bloque toujours sur le multi-ligne si mon tag est sur 2 lignes,

python est bien adapté à ce cas de figure, et la suggestion de Watael en #4 me paraît pertinente.