Bah oui, sed est dur mais c'est sed

voilà mon souci :

j'ai un fichier qui contient pleins de truc, dont -entre autres et en pagaille- des lignes de la forme suivante :


Bon. Dans mon script bash j'ai une variable magiquement nommée RACINE qui contient ce par quoi la chaine '$RACINE$' doit être remplacée pour avoir un chemin cohérent vers binaire 1&2.

Historiquement, ça vient d'un script pour openVMS ; donc à l'époque une simple substitution suffisait (et c'est ce par quoi j'ai commencé -benêt que je suis-) :


déjà, bon là je comprend pas pourquoi j'ai dû mettre 2 '\' après RACINE, sinon la regex match pas. Mais pire, vu que RACINE contient un truc du genre "~/maindir/pkg1/" le sed m'explose à la figure en me disant "Option inconnue pour 's'".
Ok, jusque là ça parait cohérent : l'expansion de variable me fout la commande sed en l'air, j'accepte.

du coup malin comme pas deux, je change la ligne dans mon script :


et ben ça marche pas mieux !!!!

et pourtant :


alors, une idée pour remplacer ce foutu '$RACINE$' par le contenu de la variable RACINE ???

------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

Sans commencer par parler de sed, c'est d'abord un problème de shell.

Ce qui est entre double quotes est interprété.
Ce qui est entre simple quote ne l'est pas.

Dans un premier temps, tu peux remplacer tes " par ', et voir ce que ça donne.

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Ceci fonctionne chez moi :



Le problème du $, c'est qu'il signifie "fin de ligne".
J'ai utilisé comme séparateur la virgule, qui n'apparait dans aucun nom de fichier, pour éviter d'avoir des problèmes d'interprétation de ce que l'on veut vraiment faire : étant donné qu'il y a des / dans ton fichier et dans $RACINE, utiliser le / entre en conflit avec le séparateur utilisé pour sed.

Sed, c'est bien

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Fanch a écrit :

J'ai peut être un début d'explication :
Tu pars de l'expressionet. Cette expression est d'abord interprétée par le shell (vu que c'est entre double quotes).
Donc sed voit respectivementet

Ensuite, comme le caractère $ signifie "fin de ligne", il ne peut avoir de véritable signification "fin de ligne" qu'à la fin d'une expression. D'où une interprétation par le caractère $ pour le $ préfixant RACINE, et l'interprétation "fin de ligne" lorsque le $ se situe à la fin de l'expression régulière. Pour que sed interprète le $ final comme un $, il faut donc l'"échapper" avec une \

Donc, sed interprèterait finalement l'expression comme ceci :et.

Au final, on a donc un \ pour empêcher l'interprétation par le shell, et un second \ pour éviter l'interprétation "fin de ligne"

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

je me doutais bien que tu répondrais, mais je pensais pas te titiller à ce point
merci beaucoup.

"sed, c'est bien" --> tu prêches un convaincu ! (en un seul mot, hein !!!)

merci pour ta solution, elle est sensiblement plus propre que celle que j'ai trouvé entre-temps :
étant relativement "bourrin" dès qu'on parle d'autre chose que de C/C++/python/C#/java, j'ai forcé l'expansion lexicale du shell avant de concaténer le tout dans la commande sed :


mais bon, vu que c'est un peu crade (et globalement très illisible pour le futur pauv' type qui devra le faire évoluer), je vais opter pour ta solution

------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

Salut,

Oui, c'est avant tout un problème de shell, d'ailleurs ceci fonctionne aussi (et on voit mieux les problèmes d'échappement dûs à sed) :


À l'inverse, pour ce qui est du problème entre caractère séparateur/chaîne à traiter, je n'ai jamais trouvé de solution à part compter sur une "standardisation" des données à l'entrée.

C'est à ma connaissance une limitation de sed (d'ailleurs en Perl ils ont eu la bonne idée d'introduire l'opérateur \Q pour ce genre de cas, c'est très pratique pour avoir un truc "sûr").

Fanch a écrit :

Surtout, ça utilise une basherie... bienvenue dans le shell et son enfer des mille implémentations...

MochiMochi > ouais mais je suis un peu peau de bache à la base

vi le shell pour moi c'est pas toujours trivial ... ça vaut pas un bon design pattern tout ça j'vous'y dis mam'Michu !

------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

Salut,

Disons que c'est aussi permissif que pauvre en structures de données (en plus de devenir vite gourmand en temps d'exécution). Donc ça devient vite une usine à gaz (ou plutôt une raffinerie avec plein de tuyaux partout) lorsqu'on cherche à faire des choses complexes.