Bonjour, J'ai toujours un peu de mal avec les regexp à la sauce sed (pourquoi il faut échapper le quantificateur + et pas * par exemple)... 1) peut-on rendre un quantificateur (* ou +) non gourmand ? (il me semble que la réponse est non, que ce soit pour le pattern de recherche de ligne ou pour la substitution, mais je ne l'ai pas trouvé explicitement) 2) pourquoi pour indiquer "tout caractère sauf un ]" il faut mettre [^]] et pas [^\]] ? 3) Plus généralement, si une bonne âme veut bien ajouter à la page http://cli.asyd.net/home/filtres/sed la liste de ce qui doit être échappé ou pas suivant les cas... Je veux bien essayer, mais ça m'ennuierait d'y écrire des bêtises. A première vue : - dans les séquences entre crochets, il ne faut echapper que . et -, et le \- (apparemment s'il est en 1er pas besoin d'échapper) - en dehors des [, echapper le + lui donne sa valeur de quantificateur mais échapper * lui retire sa valeur de quantificateur. - les () sont interprêtées comme caractères et prennent leur caractère capturant quand elles sont échappées (dans le 1er terme d'une commande s) - partout, \n et \t conservent leur sens habituel (interprêté par sed, pas par le shell car on place en général les expression sed entre quotes simple, pour éviter justement des effets de bords liés aux interprêtations du shell). Mais il me reste des cas que je m'explique mal, cf les tests suivants (avec bash 2.05b et (gnu) sed 4.1.2) s="bla bla [[http://domaine.tld/url]]-[[http://domaine2.tld/url2Plus?com=pliqu&E9e]] blabla" echo $s | sed -e 's#[]]#_#g' bla bla [[http://domaine.tld/url__-[[http://domaine2.tld/url2Plus?com=pliqu&E9e__ blabla => le crochet fermant est bien remplacé echo $s | sed -e 's#[]]*#_#g' _b_l_a_ _b_l_a_ _[_[_h_t_t_p_:_/_/_d_o_m_a_i_n_e_._t_l_d_/_u_r_l_-_[_[_h_t_t_p_:_/_/_d_o_m_a_i_n_e_2_._t_l_d_/_u_r_l_2_P_l_u_s_?_c_o_m_=_p_l_i_q_u_&_E_9_e_ _b_l_a_b_l_a_ => curieux non ? echo $s | sed -e 's#[\-]*#_#g' _b_l_a_ _b_l_a_ _[_[_h_t_t_p_:_/_/_d_o_m_a_i_n_e_._t_l_d_/_u_r_l_]_]_[_[_h_t_t_p_:_/_/_d_o_m_a_i_n_e_2_._t_l_d_/_u_r_l_2_P_l_u_s_?_c_o_m_=_p_l_i_q_u_&_E_9_e_]_]_ _b_l_a_b_l_a_ => pas tellement plus bizarre que le précédent echo $s | sed -e 's#[]]#_#g' bla bla [[http://domaine.tld/url__-[[http://domaine2.tld/url2Plus?com=pliqu&E9e__ blabla echo $s | sed -e 's#[]\-]#_#g' bla bla [[http://domaine.tld/url___[[http://domaine2.tld/url2Plus?com=pliqu&E9e__ blabla echo $s | sed -e 's#[\-]]#_#g' bla bla [[http://domaine.tld/url]]-[[http://domaine2.tld/url2Plus?com=pliqu&E9e]] blabla => tiens, ça marche plus si on les inverse... etc... -- Daniel
salut, On Mon, Jan 21, 2008 at 06:59:39PM +0100, Daniel Caillibaud wrote:
J'ai toujours un peu de mal avec les regexp à la sauce sed (pourquoi il faut échapper le quantificateur + et pas * par exemple)...
sans avoir cherché: je pense que les raisons sont historiques: cette incoherence doit être héritée des tous premiers moteurs.
1) peut-on rendre un quantificateur (* ou +) non gourmand ? (il me semble que la réponse est non, que ce soit pour le pattern de recherche de ligne ou pour la substitution, mais je ne l'ai pas trouvé explicitement)
tant que je sache: la réponse est non.
2) pourquoi pour indiquer "tout caractère sauf un ]" il faut mettre [^]] et pas [^\]] ?
parceque dans les metacaractères, c'est la place du crochet qui determine le fait qu'on parle bien du symbole lui-même.
echo '[aze]aAbAc' | sed 's/[^][]//g' []
3) Plus généralement, si une bonne âme veut bien ajouter à la page http://cli.asyd.net/home/filtres/sed la liste de ce qui doit être échappé ou pas suivant les cas...
et par là réécrire man regex ? je ne crois pas que ce soit utile.
A première vue : - dans les séquences entre crochets, il ne faut echapper que . et -, et le \- (apparemment s'il est en 1er pas besoin d'échapper)
idem que pour le crochet: c'est la position (1er ou dernier) qui rend au symbole son simple rang. De manière générale, je crois qu'il ne faut pas tenter de retenir les règles mais tenter de les déduire: [a-z] < - a un sens [az-] < - n'a pas de sens [-az] < - n'a pas de sens
- partout, \n et \t conservent leur sens habituel (interprêté par sed, pas par le shell car on place en général les expression sed entre quotes simple, pour éviter justement des effets de bords liés aux interprêtations du shell).
et \v, et autres ...
s="bla bla [[http://domaine.tld/url]]-[[http://domaine2.tld/url2Plus?com=pliqu&E9e]] blabla"
echo $s | sed -e 's#[]]*#_#g' _b_l_a_ _b_l_a_ _[_[_h_t_t_p_:_/_/_d_o_m_a_i_n_e_._t_l_d_/_u_r_l_-_[_[_h_t_t_p_:_/_/_d_o_m_a_i_n_e_2_._t_l_d_/_u_r_l_2_P_l_u_s_?_c_o_m_=_p_l_i_q_u_&_E_9_e_ _b_l_a_b_l_a_ => curieux non ?
non! A* signifie : de 0 a n fois le motif A. 0 donc chaine vide matche aussi. Il y a une chaine vide entre chaque caracteres. marc
Marc Chantreux a écrit :
3) Plus généralement, si une bonne âme veut bien ajouter à la page http://cli.asyd.net/home/filtres/sed la liste de ce qui doit être échappé ou pas suivant les cas...
et par là réécrire man regex ? je ne crois pas que ce soit utile.
Sauf qu'il y a plusieurs spécificités liées à sed (le '+' et les '()' par exemple, je ne sais pas s'il y en a d'autres). Par ailleur man regex ne parle pas des caractères à échapper ou pas, ni de la syntaxe.
idem que pour le crochet: c'est la position (1er ou dernier) qui rend au symbole son simple rang. De manière générale, je crois qu'il ne faut pas tenter de retenir les règles mais tenter de les déduire:
Je suis d'accord, sauf que j'ai du mal à comprendre la logique...
[a-z] < - a un sens [az-] < - n'a pas de sens [-az] < - n'a pas de sens
Ben si, "tiret, a ou z" (mon sed interprête les 2 comme ça) echo '[aze]a-AbAc' | sed -e 's#[-az]#_#g' [__e]__AbAc Mon pb est de comprendre quand le \ signifie "échapper le caractère qui suit" et quand il signifie "caractère backslash". Il me semble que là dessus, sed fonctionne différemment des autres outils qui utilisent les regexp (le pb vient sûrement de la différence regex posix et regex PCRE que j'ai davantage l'habitude de manipuler). echo '[aze]\-]a-Ab\Ac' | sed -e 's#[\]-]#_#g' [aze]_a-Ab\Ac echo '[aze]\-]a-Ab\Ac' | sed -e 's#[]\-]#_#g' [aze____a_Ab_Ac echo '[aze]\-]a-Ab\Ac' | sed -e 's#\-]#_#g' [aze]\_a-Ab\Ac echo '[aze]\-]a-Ab\Ac' | sed -e 's#\\-]#_#g' [aze]_a-Ab\Ac Apparemment, le \ est toujours pris comme un caractère quand il est entre [], et jamais en dehors, d'où la difficulté quand on cherche du crochet fermant et du tiret (et autre chose), ça me parait pa immédiat de savoir qu'il faut commencer par crochet fermant puis tiret puis le reste. Daniel PS:
Il y a une chaine vide entre chaque caracteres.
Ben oui, truc évident que j'ai zappé dans mes tests, du a* n'a pas de sens tout seul, mais à vouloir tester chaque petit bout isolément j'ai finit par écrire n'importe quoi.
Daniel Caillibaud wrote:
Mon pb est de comprendre quand le \ signifie "échapper le caractère qui suit" et quand il signifie "caractère backslash". Il me semble que là dessus, sed fonctionne différemment des autres outils qui utilisent les regexp (le pb vient sûrement de la différence regex posix et regex PCRE que j'ai davantage l'habitude de manipuler).
echo '[aze]\-]a-Ab\Ac' | sed -e 's#[\]-]#_#g' [aze]_a-Ab\Ac
echo '[aze]\-]a-Ab\Ac' | sed -e 's#[]\-]#_#g' [aze____a_Ab_Ac
echo '[aze]\-]a-Ab\Ac' | sed -e 's#\-]#_#g' [aze]\_a-Ab\Ac
echo '[aze]\-]a-Ab\Ac' | sed -e 's#\\-]#_#g' [aze]_a-Ab\Ac
Apparemment, le \ est toujours pris comme un caractère quand il est entre [], et jamais en dehors, d'où la difficulté quand on cherche du crochet fermant et du tiret (et autre chose), ça me parait pa immédiat de savoir qu'il faut commencer par crochet fermant puis tiret puis le reste.
Re, Vraiment dans tes quatre exemples je ne vois pas ce qu'il y a de compliqué. Dans le premier cas, le premier caractère après le [ est le \, suivit du ], ça correspond bien à "caractère backslash'. Dans le deuxième cas, le premier caractère après le [ est ]. Le ] est donc un caractère pris en compte au même titre que \ et -. C'est donc ] ou - ou \. Dans le cas d'après pas de [, chaque caractère est interprété. En dehors de [], \ est effectivement un caractère d'échappement. Donc \-] signifie - puis ]. Enfin pour le dernier exemple, tu as un backslash et un tiret. Rien de plus simple. Vraiment, je ne suis pas un grand gourou de sed et pour tout dire, je ne l'ai pratiquement jamais utilisé, mais je ne vois vraiment pas comment, dans les exemples que tu as donné, on pourrait arriver à un autre résultat, et donc en quoi ces résultats sont surprenants ou, selon toi, imprévisibles. -- À++ theo.
theo a écrit :
et donc en quoi ces résultats sont surprenants ou, selon toi, imprévisibles.
On pourrait s'attendre par exemple à ce que \ à l'intérieur de [] serve à échapper le caractère suivant (notamment quand le caractère suivant à une signification particulière comme '-' ou ']'). Pour matcher un \, il en faut deux en dehors des [] mais un seul à l'intérieur. On pourrait aussi s'attendre à ce que [\-~] désigne les cars entre 92 et 126, ou bien l'un des 3 car, mais ça prend pas le - echo '[aze]\-]a-A~b\Ac' | sed -e 's#[\-~]#_#g' [aze]_-]a-A_b_Ac On pourrait aussi penser [Z-a] désigne les caractères entre 90 et 97 et ça répond "Invalid range end". Bref, je ne trouve pas ça si "évident" que ça... -- Daniel
On Wed, Jan 23, 2008 at 05:42:47PM +0100, Daniel Caillibaud wrote:
theo a écrit : On pourrait s'attendre par exemple à ce que \ à l'intérieur de [] serve à échapper le caractère suivant (notamment quand le caractère suivant à une signification particulière comme '-' ou ']').
j'espere que mon explication aura suffit.
On pourrait aussi s'attendre à ce que [\-~] désigne les cars entre 92 et 126, ou bien l'un des 3 car, mais ça prend pas le -
heuu ... je dois l'avouer ? vraiment ? c'est un peu humiliant mais je suppose que c'est un peu comme dans une thérapie de groupe: le premier qui parle détend les autres ... Ne riez pas, hein ... mais ... je n'ai pas fini d'apprendre par coeur la table ascii. je n'aurais donc pas été foutu de te dire que \ est avant ~. voila ... c'est dit! je pense que beaucoup d'entre nous n'ont retenu que 3 ranges, et ce sont a mon avis les 3 ranges possibles ( avec leurs sous-ensembles): a-z A-Z 0-9 et c'est a mon avis les 3 seuls ranges qui fonctionnent. UTSL si tu veux vérifier.
On pourrait aussi s'attendre à ce que [\-~] désigne les cars entre 92 et 126, ou bien l'un des 3 car, mais ça prend pas le -
le comportement n'est pas logique, je te l'accorde, mais ca peut s'expliquer: dans un cas tordu comme celui-ci, les seuls caractères du range dont on soit sur sont ceux qui ont été exprimés. c'est bien un range parceque j'utilisateur l'aurait écrit différement sinon ( [-\~]). on garde alors ce que nous avons de sur soir \ et ~. La aussi: UTSL.
On pourrait aussi penser [Z-a] désigne les caractères entre 90 et 97 et ça répond "Invalid range end".
meme raison.
Le 27 janv. 08 à 10:12, Marc Chantreux a écrit :
On pourrait aussi s'attendre à ce que [\-~] désigne les cars entre 92 et 126, ou bien l'un des 3 car, mais ça prend pas le -
le comportement n'est pas logique, je te l'accorde, mais ca peut s'expliquer: dans un cas tordu comme celui-ci, les seuls caractères du range dont on soit sur sont ceux qui ont été exprimés. c'est bien un range parceque j'utilisateur l'aurait écrit différement sinon ( [- \~]). on garde alors ce que nous avons de sur soir \ et ~. La aussi: UTSL.
On pourrait aussi penser [Z-a] désigne les caractères entre 90 et 97 et ça répond "Invalid range end".
meme raison.
NON, jeune padawan ! Il s'agit de locale. Dans les locales françaises *sous linux*, le A et le a sont dans la même classe de caractère pour le tri, or sed est un programme sensible aux locales, donc sed, en français, voit [Z-a] comme [z-a] ou [z-A] ou [Z-A]. Je dis sous linux, car sous mac OSX (10.5), bien que mon mac me parle frenchy, j'ai pas ce problème de tri (mais j'ai pas de variables LC_* ou LANG* non plus) exemple sous linux en français, A et a sont identique : $ locale LANG=fr LANGUAGE=fr_FR:fr:en_GB:en LC_CTYPE="fr_FR" LC_NUMERIC="fr_FR" LC_TIME="fr_FR" LC_COLLATE="fr_FR" LC_MONETARY="fr_FR" LC_MESSAGES="fr_FR" LC_PAPER="fr_FR" LC_NAME="fr_FR" LC_ADDRESS="fr_FR" LC_TELEPHONE="fr_FR" LC_MEASUREMENT="fr_FR" LC_IDENTIFICATION="fr_FR" LC_ALL=fr_FR $ mkdir TOTO $ cd TOTO $ touch a b c d A B C D Z z $ ls | cat a A b B c C d D z Z $ env LC_ALL=C ls | cat A B C D Z a b c d z et du coup $ ls | sed -e '/[Z-a]/d' sed: -e expression n°1, caractère 7: Fin d'intervalle invalide $ ls | env LC_ALL=C sed -e '/[Z-a]/d' A b B c C d D z quant à [\-~] C'est du délire total en français, par contre, sans traduction, ça marche bien. $ echo 'Aa b- c~ dZ' | env LC_ALL=C sed -e 's/[\-~]//g' A - Z $ echo 'Aa b- c~ dZ' | sed -e 's/[\-~]//g' Aa b- c dZ Un volontaire pour se palucher les codes source de la gnu libc et de sed et expliquer ça ? ;-) Voilà ! Les applications internationalisées obéissent normalement aux variables d'environnement LANG, ou LC_* (LC_COLLATE pour le tri) ou LC_ALL si LC_ALL est définie. Si quelqu'un peut m'expliquer le rôle de la variable LANGUAGE (extension GNU), je suis preneur. Dans le même genre de ç&é"!(çà"!è!è'"§!&"#(!§ç!&"à!ç§&@## en français il y a les nombres à virgule, et pas à point. On se fait tjrs avoir une fois ou deux avec awk (et perl ?) sur des nombres tels 1254.12 tronqués à 1254 car le système attendait, en français, 1254,12 Christophe
On Mon, Jan 28, 2008 at 10:43:58AM +0100, Christophe Martin wrote:
On pourrait aussi penser [Z-a] désigne les caractères entre 90 et 97 et ça répond "Invalid range end".
meme raison. NON, jeune padawan !
si, si ...: "raison technique dont je me cogne" peut importe la raison technique profonde: il reste que a-Z Z-a ou :-) sont des classes tordues a lors de redactions de scripts. marc
On Mon, Jan 28, 2008 at 10:43:58AM +0100, Christophe Martin wrote:
On pourrait aussi penser [Z-a] désigne les caractères entre 90 et 97 et ça répond "Invalid range end".
meme raison. NON, jeune padawan !
si, si ...: "raison technique dont je me cogne" Quelle mauvaise foi ! Tu peux toujours t'en cogner, ça changera pas les
Le 28 janv. 08 à 12:46, Marc Chantreux a écrit : programmes ni leur comportement. En revanche, ceux qui ont lu et pris la peine de comprendre, savent maintenant qu'ils s'agit d'un problème de locale. Figure toi qu'ils peuvent même trouver une solution à leur problème.
peut importe la raison technique profonde: il reste que a-Z Z-a ou :-) sont des classes tordues a lors de redactions de scripts. Bien sur ! Il devrait être interdit d'utiliser autre chose que a-z
Christophe
On Mon, Jan 28, 2008 at 03:07:21PM +0100, Christophe Martin wrote:
si, si ...: "raison technique dont je me cogne" Quelle mauvaise foi !
a peine :) bon ... j'avoue que c'est intéressant de le savoir mais il n'empeche qu'en pratique : je n'utiliserais jamais ce genre de meta.
peut importe la raison technique profonde: il reste que a-Z Z-a ou :-) sont des classes tordues a lors de redactions de scripts. Bien sur ! Il devrait être interdit d'utiliser autre chose que a-z
c'est ironique ?
Bonjour, On 2008-01-28 10:43:58 +0100, Christophe Martin wrote:
$ touch a b c d A B C D Z z $ ls | cat a A b B c C d D z Z
"ls -1" est plus élégant que "ls | cat": vin:~tmp/test> LC_COLLATE=fr_FR ls -1 a A b B c C d D z Z et au lieu de créer des fichiers, on peut utiliser sort: vin:~> printf "%s\n" a b c d A B C D Z z | LC_COLLATE=fr_FR sort a A b B c C d D z Z
quant à [\-~] C'est du délire total en français, par contre, sans traduction, ça marche bien. $ echo 'Aa b- c~ dZ' | env LC_ALL=C sed -e 's/[\-~]//g' A - Z $ echo 'Aa b- c~ dZ' | sed -e 's/[\-~]//g' Aa b- c dZ
Ça semble supprimer les caractères suivants: vin:~> perl -e 'for (32..126, 160..255) { printf "%3d <%c%c>\n", $_, $_, $_ }' | LC_COLLATE=fr_FR sed -e 's/[\-~]//' | grep ' <.>$' 35 <#> 37 <%> 38 <&> 43 <+> 92 <\> 94 <^> 96 <`> 126 <~> 168 <¨> 177 <±> 180 <´> La spécification donnée dans la page man regex(7): A bracket expression is a list of characters enclosed in `[]'. It normally matches any single character from the list (but see below). If the list begins with `^', it matches any single character (but see below) not from the rest of the list. If two characters in the list are separated by `-', this is shorthand for the full range of charac- ters between those two (inclusive) in the collating sequence, for example, `[0-9]' in ASCII matches any decimal digit. It is ille- gal(!) for two ranges to share an endpoint, for example, `a-c-e'. Ranges are very collating-sequence-dependent, and portable programs should avoid relying on them.
Si quelqu'un peut m'expliquer le rôle de la variable LANGUAGE (extension GNU), je suis preneur.
Je crois que l'unique but est de pouvoir définir une liste de langues. Ce n'est pas supporté par tout. "info libc" indique: This looks very familiar. With the exception of the `LANGUAGE' environment variable this is exactly the lookup order the `setlocale' function uses. But why introducing the `LANGUAGE' variable? The reason is that the syntax of the values these variables can have is different to what is expected by the `setlocale' function. If we would set `LC_ALL' to a value following the extended syntax that would mean the `setlocale' function will never be able to use the value of this variable as well. An additional variable removes this problem plus we can select the language independently of the locale setting which sometimes is useful. While for the `LC_xxx' variables the value should consist of exactly one specification of a locale the `LANGUAGE' variable's value can consist of a colon separated list of locale names. The attentive reader will realize that this is the way we manage to implement one of our additional demands above: we want to be able to specify an ordered list of language.
Dans le même genre de ç&é"!(çà"!è!è'"§!&"#(!§ç!&"à!ç§&@## en français il y a les nombres à virgule, et pas à point. On se fait tjrs avoir une fois ou deux avec awk (et perl ?) sur des nombres tels 1254.12 tronqués à 1254 car le système attendait, en français, 1254,12
Pour info, dans MPFR, on accepte les deux formes: la forme avec un
point, et celle avec le decimal_point de la locale courante.
--
Vincent Lefèvre
Re bonjour, Le 28 janv. 08 à 12:49, Vincent Lefevre a écrit :
Bonjour,
On 2008-01-28 10:43:58 +0100, Christophe Martin wrote:
$ touch a b c d A B C D Z z $ ls | cat [couic]
"ls -1" est plus élégant que "ls | cat":
Ça semble supprimer les caractères suivants:
vin:~> perl -e 'for (32..126, 160..255) { printf "%3d <%c%c>\n", $_, $_, $_ }' | LC_COLLATE=fr_FR sed -e 's/[\-~]//' | grep ' <.>$' Joli, mais y'avait plus léger ;-)
[zap] perl -e 'for (32..126, 160..255) { printf "%3d <%c>\n", $_, $_ }' | LC_COLLATE=fr_FR sed -ne '/[\-~]/p'
Si quelqu'un peut m'expliquer le rôle de la variable LANGUAGE (extension GNU), je suis preneur.
Je crois que l'unique but est de pouvoir définir une liste de langues. Ce n'est pas supporté par tout.
"info libc" indique:
Merci pour cette piste. me reste à faire qq tests pour tout comprendre. [couic]
Pour info, dans MPFR, on accepte les deux formes: la forme avec un point, et celle avec le decimal_point de la locale courante.
Une très bonne idée, à n'en pas douter. Christophe.
dear theo, je viens de réexpliquer ce que tu viens de dire .. ne m'en tiens pas rigeur mais il semble que Daniel aie vraiment un problème avec ce concept. 2 explications valant mieux qu'une ... cordialement, marc
re, je réponds dans le désordre ... mais c'est pour être le plus clair possible.
Mon pb est de comprendre quand le \ signifie "échapper le caractère qui suit" et quand il signifie "caractère backslash.
l'utilisation du \ en sed est en fait plus deductible que dans bien des moteurs mai aussi tellement plus chiante à l'écriture! Il y a deux règles: Lorsque je suis dans un contexte de description du motif ( hors de [], donc), tous les caractères qui ont une signification pour le moteur est protégé (a l'exception de *). Ainsi \( ouvre une capture et ( est le symbole (. Lorsque je suis dans un contexte d'une définition de métacaractère (dans [], donc), il n'existe plus que 2 caractères spéciaux. * ] qui ferme la définition du métacaractère * - qui est le séparateur entre 2 extrémités d'une suite ( a-z ) Ces caractères perdent leur signification si ils sont placés de telle facon que leur utilisation *en temps que caractère spécial* est un non-sens (oui, je reviens avec ca!). le \ est donc inutile. donc je reprend mes exemples et j'en ajoute un: * [] quel intéret de déclarer un metacaractère vide? Aucun? donc le ] est un simple symbole.
[a-z] < - a un sens
n'importe quel caractère entre a et z
[az-] < - n'a pas de sens
a, et de z à l'infini? je maintiens: ca n'a pas de sens
[-az] < - n'a pas de sens
z, et de l'infini à a ? je maintiens: ca n'a pas de sens
Apparemment, le \ est toujours pris comme un caractère quand il est entre [],
u got it! tout simplement parcequ'il est inutile :)
et jamais en dehors, d'où la difficulté
ben ... je trouve au contraire que c'est ultra logique: * jamais quand dans [] * toujours quand hors []
quand on cherche du crochet fermant et du tiret (et autre chose), ça me parait pa immédiat de savoir qu'il faut commencer par crochet fermant puis tiret puis le reste.
j'espere que mon explication t'aidera.
Marc Chantreux a écrit :
Mon pb est de comprendre quand le \ signifie "échapper le caractère qui suit" et quand il signifie "caractère backslash.
l'utilisation du \ en sed est en fait plus deductible que dans bien des moteurs mai aussi tellement plus chiante à l'écriture! Il y a deux règles:
Lorsque je suis dans un contexte de description du motif ( hors de [], donc), tous les caractères qui ont une signification pour le moteur est protégé (a l'exception de *
et aussi de '.' et '['. Pourquoi ces 3 là et pas d'autres ? C'était un peu le sens de ma question initiale.
). Ainsi \( ouvre une capture et ( est le symbole (.
[...]
ben ... je trouve au contraire que c'est ultra logique:
Mouais, c'est là que je suis moyennement convaincu. J'ai assimilé la règle, mais avec pas mal de coups sur la tête comme vous avez pu le constater. Je ne me rappelle pas avoir tatonné à ce point avec les PCRE qui me semblent plus claire avec "certains caractères ont une signification particulière et doivent être échappés pour redevenir de simples caratères" et l'a priori "le \ échappe toujours le caractère qui suit, même si c'était inutile de le faire" qui conduit c'est vrai à adopter le profil "dans le doute, échappe" ;-). Bref, sed me paraitrait plus logique s'il fallait échapper aussi . * et [] pour leur donner leur signification particulière spécifiques aux regexp (mais la lecture et l'écriture deviendrait atroce, je le reconnais...). J'ai essayé de résumer tout ça sur http://cli.asyd.net/home/filtres/sed#echappement_des_caracteres, merci de jeter un oeil (c'est court) et d'ajouter ce qui manque (pas d'autres exceptions notamment). -- Daniel
On Mon, Jan 28, 2008 at 11:42:14AM +0100, Daniel Caillibaud wrote:
Pourquoi ces 3 là et pas d'autres ? C'était un peu le sens de ma question initiale.
hmm ... je pense que beaucoup de commandes trainent leur histoire.
vous avez pu le constater. Je ne me rappelle pas avoir tatonné à ce point avec les PCRE qui me semblent plus claire avec
une BMW est donc plus confortable qu'une citroen ? je le note ;) ++
Marc Chantreux a écrit :
... les PCRE qui me semblent plus claire avec
une BMW est donc plus confortable qu'une citroen ? je le note ;)
Moqueur va ;-) Et ton adjectif "confortable" est un peu limite, "simple à utiliser" serait plus adapté, et dans ce cas cela peut sembler paradoxal qu'une BMW soit plus simple qu'une 2CV (Citroën a aussi fait les DS et autres SM...). -- Daniel
Daniel Caillibaud wrote: lut,
2) pourquoi pour indiquer "tout caractère sauf un ]" il faut mettre [^]] et pas [^\]] ?
Parce que [^] n'aurait aucun sens autrement. Cela voudrait dire "tout sauf rien". Le premier caractère après le ^ est obligatoirement un caractère matché. L'exemple de Marc : echo "[abc]def" | sed "s/[^][]//g" [] Les caractères ignorés sont ] et [. Si on tente de les mettre dans l'autre sens : echo "[abc]def" | sed "s/[^[]]//g" [abdef Ça ne fonctionne pas. Ça ne s'interprète pas comme tout sauf [], mais "tout sauf [" (la partie [^[]) puis ]. Ce qui matche bien c]. -- À + theo.
On lun 21 janvier, Daniel Caillibaud wrote:
Bonjour,
[..]
Je veux bien essayer, mais ça m'ennuierait d'y écrire des bêtises.
T'a plus le choix maintenant :) -- http://asyd.net/home/ - Home Page http://guses.org/home/ - French Speaking (Open)Solaris User Group
participants (6)
-
Bruno Bonfils -
Christophe Martin -
Daniel Caillibaud -
Marc Chantreux -
theo -
Vincent Lefevre