j'ai une interrogation à laquelle je ne trouve pas vraiment de réponse.
Les expressions rationnelles permettent de créer des motifs à utiliser
avec diverses commandes Unix, mais leur utilisation dépend en fait de la
commande utilisée, sans que je comprenne la logique de la chose.
Par exemple, prenons le caractère * qui, utilisé avec ls correspond à
n'importe quelle chaîne de caractère et qui utilisée dans find /rep
-name "essai*" signifie plusieurs répétitions du caractère précédent (i
dans mon exemple).
Je sais dans quel cas je peux utiliser telle syntaxe, mais je me demande
où est la logique ?
Vincent Verdon wrote in message <4af09506$0$7791$:
Par exemple, prenons le caractère * qui, utilisé avec ls correspond à n'importe quelle chaîne de caractère
Non, pas du tout. Le caractère *, utilisé avec ls, signifie le caractère * et rien d'autre. Quand on écrit « ls * », c'est le shell qui interprète le caractère *, ls ne le voit jamais, il est remplacé par la liste des fichiers.
et qui utilisée dans find /rep -name "essai*" signifie plusieurs répétitions du caractère précédent (i dans mon exemple).
Non, ce n'est pas vrai : l'argument de find -name obéit en gros aux mêmes règles que l'expansion de noms du shell.
Qui, soit dit en passant, ne sont pas du tout des expressions rationnelles.
Je sais dans quel cas je peux utiliser telle syntaxe, mais je me demande où est la logique ?
La logique réside dans le fait de chercher à fournir l'interface la plus pratique possible : les règles d'expansion de noms (glob) sont plus pratiques pour les noms de fichiers, les expressions rationnelles sont plus générales. Donc un programme qui traite essentiellement des noms de fichiers aura plutôt intérêt à implémenter du glob, et un programme qui traite du texte général aura plutôt intérêt à implémenter des expressions rationnelles.
Vincent Verdon wrote in message
<4af09506$0$7791$426a34cc@news.free.fr>:
Par exemple, prenons le caractère * qui, utilisé avec ls correspond à
n'importe quelle chaîne de caractère
Non, pas du tout. Le caractère *, utilisé avec ls, signifie le caractère *
et rien d'autre. Quand on écrit « ls * », c'est le shell qui interprète le
caractère *, ls ne le voit jamais, il est remplacé par la liste des
fichiers.
et qui utilisée dans find /rep
-name "essai*" signifie plusieurs répétitions du caractère précédent (i
dans mon exemple).
Non, ce n'est pas vrai : l'argument de find -name obéit en gros aux mêmes
règles que l'expansion de noms du shell.
Qui, soit dit en passant, ne sont pas du tout des expressions rationnelles.
Je sais dans quel cas je peux utiliser telle syntaxe, mais je me demande
où est la logique ?
La logique réside dans le fait de chercher à fournir l'interface la plus
pratique possible : les règles d'expansion de noms (glob) sont plus
pratiques pour les noms de fichiers, les expressions rationnelles sont plus
générales. Donc un programme qui traite essentiellement des noms de fichiers
aura plutôt intérêt à implémenter du glob, et un programme qui traite du
texte général aura plutôt intérêt à implémenter des expressions
rationnelles.
Vincent Verdon wrote in message <4af09506$0$7791$:
Par exemple, prenons le caractère * qui, utilisé avec ls correspond à n'importe quelle chaîne de caractère
Non, pas du tout. Le caractère *, utilisé avec ls, signifie le caractère * et rien d'autre. Quand on écrit « ls * », c'est le shell qui interprète le caractère *, ls ne le voit jamais, il est remplacé par la liste des fichiers.
et qui utilisée dans find /rep -name "essai*" signifie plusieurs répétitions du caractère précédent (i dans mon exemple).
Non, ce n'est pas vrai : l'argument de find -name obéit en gros aux mêmes règles que l'expansion de noms du shell.
Qui, soit dit en passant, ne sont pas du tout des expressions rationnelles.
Je sais dans quel cas je peux utiliser telle syntaxe, mais je me demande où est la logique ?
La logique réside dans le fait de chercher à fournir l'interface la plus pratique possible : les règles d'expansion de noms (glob) sont plus pratiques pour les noms de fichiers, les expressions rationnelles sont plus générales. Donc un programme qui traite essentiellement des noms de fichiers aura plutôt intérêt à implémenter du glob, et un programme qui traite du texte général aura plutôt intérêt à implémenter des expressions rationnelles.
Vincent Verdon
Bonjour,
Nicolas George a écrit :
Vincent Verdon wrote in message <4af09506$0$7791$:
Par exemple, prenons le caractère * qui, utilisé avec ls correspond à n'importe quelle chaîne de caractère
Non, pas du tout. Le caractère *, utilisé avec ls, signifie le caractère * et rien d'autre. Quand on écrit « ls * », c'est le shell qui interprète le caractère *, ls ne le voit jamais, il est remplacé par la liste des fichiers.
et qui utilisée dans find /rep -name "essai*" signifie plusieurs répétitions du caractère précédent (i dans mon exemple).
Non, ce n'est pas vrai : l'argument de find -name obéit en gros aux mêmes règles que l'expansion de noms du shell.
Oups ! Je me suis trompé. Je pensais à grep en fait...
Qui, soit dit en passant, ne sont pas du tout des expressions rationnelles.
Je sais dans quel cas je peux utiliser telle syntaxe, mais je me demande où est la logique ?
La logique réside dans le fait de chercher à fournir l'interface la plus pratique possible : les règles d'expansion de noms (glob) sont plus pratiques pour les noms de fichiers, les expressions rationnelles sont plus générales. Donc un programme qui traite essentiellement des noms de fichiers aura plutôt intérêt à implémenter du glob, et un programme qui traite du texte général aura plutôt intérêt à implémenter des expressions rationnelles.
Là effectivement, je comprends mieux.
Merci beaucoup pour la réponse.
Amicalement, Vincent Verdon
Bonjour,
Nicolas George a écrit :
Vincent Verdon wrote in message
<4af09506$0$7791$426a34cc@news.free.fr>:
Par exemple, prenons le caractère * qui, utilisé avec ls correspond à
n'importe quelle chaîne de caractère
Non, pas du tout. Le caractère *, utilisé avec ls, signifie le caractère *
et rien d'autre. Quand on écrit « ls * », c'est le shell qui interprète le
caractère *, ls ne le voit jamais, il est remplacé par la liste des
fichiers.
et qui utilisée dans find /rep
-name "essai*" signifie plusieurs répétitions du caractère précédent (i
dans mon exemple).
Non, ce n'est pas vrai : l'argument de find -name obéit en gros aux mêmes
règles que l'expansion de noms du shell.
Oups ! Je me suis trompé. Je pensais à grep en fait...
Qui, soit dit en passant, ne sont pas du tout des expressions rationnelles.
Je sais dans quel cas je peux utiliser telle syntaxe, mais je me demande
où est la logique ?
La logique réside dans le fait de chercher à fournir l'interface la plus
pratique possible : les règles d'expansion de noms (glob) sont plus
pratiques pour les noms de fichiers, les expressions rationnelles sont plus
générales. Donc un programme qui traite essentiellement des noms de fichiers
aura plutôt intérêt à implémenter du glob, et un programme qui traite du
texte général aura plutôt intérêt à implémenter des expressions
rationnelles.
Vincent Verdon wrote in message <4af09506$0$7791$:
Par exemple, prenons le caractère * qui, utilisé avec ls correspond à n'importe quelle chaîne de caractère
Non, pas du tout. Le caractère *, utilisé avec ls, signifie le caractère * et rien d'autre. Quand on écrit « ls * », c'est le shell qui interprète le caractère *, ls ne le voit jamais, il est remplacé par la liste des fichiers.
et qui utilisée dans find /rep -name "essai*" signifie plusieurs répétitions du caractère précédent (i dans mon exemple).
Non, ce n'est pas vrai : l'argument de find -name obéit en gros aux mêmes règles que l'expansion de noms du shell.
Oups ! Je me suis trompé. Je pensais à grep en fait...
Qui, soit dit en passant, ne sont pas du tout des expressions rationnelles.
Je sais dans quel cas je peux utiliser telle syntaxe, mais je me demande où est la logique ?
La logique réside dans le fait de chercher à fournir l'interface la plus pratique possible : les règles d'expansion de noms (glob) sont plus pratiques pour les noms de fichiers, les expressions rationnelles sont plus générales. Donc un programme qui traite essentiellement des noms de fichiers aura plutôt intérêt à implémenter du glob, et un programme qui traite du texte général aura plutôt intérêt à implémenter des expressions rationnelles.
Là effectivement, je comprends mieux.
Merci beaucoup pour la réponse.
Amicalement, Vincent Verdon
Cyrille Lefevre
Bonjour,
pour compliquer un peu la chose, nous avons les BRE et les ERE, BRE pour basic regular expression et REE pour extended regular expression . regular expression se traduisant en français comme expression rationnel et non régulière ! les BRE sont urilisées pas grep, ed et sed. les ERE par egrep et awk essentiellement. le shell (et find) utilise, lui, des patterns, autrement dit, des express ions shell, je ne connais pas d'autre traduction :( direction le jargon français ?
les grosses différences sont :
shell ksh BRE ERE * * .* .* ? ? . . [a-z] idem idem idem +(?) .{1,} .+ ?(?) .{0,1} .? .{1,3} ?{1,3} @(x|y) (x|y) !(x|y)
ksh == bash + shopt -s extglob
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression... qui permettent de faire des truc vraiment barbare et incompréhensible, à la perl, quoi :-)
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Bonjour,
pour compliquer un peu la chose, nous avons les BRE et les ERE,
BRE pour basic regular expression et REE pour extended regular expression .
regular expression se traduisant en français comme expression rationnel et non régulière !
les BRE sont urilisées pas grep, ed et sed.
les ERE par egrep et awk essentiellement.
le shell (et find) utilise, lui, des patterns, autrement dit, des express ions shell,
je ne connais pas d'autre traduction :( direction le jargon français ?
les grosses différences sont :
shell ksh BRE ERE
* * .* .*
? ? . .
[a-z] idem idem idem
+(?) .{1,} .+
?(?) .{0,1} .?
.{1,3} ?{1,3}
@(x|y) (x|y)
!(x|y)
ksh == bash + shopt -s extglob
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression...
qui permettent de faire des truc vraiment barbare et incompréhensible, à la perl, quoi :-)
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
pour compliquer un peu la chose, nous avons les BRE et les ERE, BRE pour basic regular expression et REE pour extended regular expression . regular expression se traduisant en français comme expression rationnel et non régulière ! les BRE sont urilisées pas grep, ed et sed. les ERE par egrep et awk essentiellement. le shell (et find) utilise, lui, des patterns, autrement dit, des express ions shell, je ne connais pas d'autre traduction :( direction le jargon français ?
les grosses différences sont :
shell ksh BRE ERE * * .* .* ? ? . . [a-z] idem idem idem +(?) .{1,} .+ ?(?) .{0,1} .? .{1,3} ?{1,3} @(x|y) (x|y) !(x|y)
ksh == bash + shopt -s extglob
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression... qui permettent de faire des truc vraiment barbare et incompréhensible, à la perl, quoi :-)
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Olivier Miakinen
[Copie et suivi vers fr.comp.lang.regexp]
Le 04/11/2009 23:55, Cyrille Lefevre a écrit :
pour compliquer un peu la chose, nous avons les BRE et les ERE, BRE pour basic regular expression et ERE pour extended regular expression. regular expression se traduisant en français comme expression rationnelle et non régulière ! les BRE sont utilisées par grep, ed et sed. les ERE par egrep et awk essentiellement. le shell (et find) utilise, lui, des patterns, autrement dit, des expressions shell, je ne connais pas d'autre traduction :( direction le jargon français ?
les grosses différences sont :
shell ksh BRE ERE * * .* .* ? ? . . [a-z] idem idem idem +(?) .{1,} .+ ?(?) .{0,1} .? .{1,3} ?{1,3} @(x|y) (x|y) !(x|y)
ksh == bash + shopt -s extglob
Merci pour ce bref résumé.
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression...
« perl compatible regular expression » : il s'agit d'un sur-ensemble des expressions rationnelles de Perl 5.
qui permettent de faire des truc vraiment barbares et incompréhensibles, à la perl, quoi :-)
;-)
Je signale au passage que le JavaScript actuellement implémenté dans la plupart des navigateurs web (ECMA-262 édition 3) utilise les expressions rationnelles de Perl 5, alors que PHP dispose d'un ensemble de fonctions PCRE. PHP a aussi un exemple de fonctions pour des expressions POSIX, je crois qu'il s'agit des ERE.
Enfin, je fais suivre la discussion vers fr.comp.lang.regexp.
P.-S. : Cyrille, tes lignes sont trop longues. Tu ne t'en rends pas compte à cause du format flowed, mais tu devrais remettre la limite à 72 caractères (ça ne changera rien pour toi mais ce sera mieux pour les autres).
Cordialement, -- Olivier Miakinen
[Copie et suivi vers fr.comp.lang.regexp]
Le 04/11/2009 23:55, Cyrille Lefevre a écrit :
pour compliquer un peu la chose, nous avons les BRE et les ERE,
BRE pour basic regular expression et ERE pour extended regular expression.
regular expression se traduisant en français comme expression rationnelle et non régulière !
les BRE sont utilisées par grep, ed et sed.
les ERE par egrep et awk essentiellement.
le shell (et find) utilise, lui, des patterns, autrement dit, des expressions shell,
je ne connais pas d'autre traduction :( direction le jargon français ?
les grosses différences sont :
shell ksh BRE ERE
* * .* .*
? ? . .
[a-z] idem idem idem
+(?) .{1,} .+
?(?) .{0,1} .?
.{1,3} ?{1,3}
@(x|y) (x|y)
!(x|y)
ksh == bash + shopt -s extglob
Merci pour ce bref résumé.
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression...
« perl compatible regular expression » : il s'agit d'un sur-ensemble des
expressions rationnelles de Perl 5.
qui permettent de faire des truc vraiment barbares et incompréhensibles, à la perl, quoi :-)
;-)
Je signale au passage que le JavaScript actuellement implémenté dans la
plupart des navigateurs web (ECMA-262 édition 3) utilise les expressions
rationnelles de Perl 5, alors que PHP dispose d'un ensemble de fonctions
PCRE. PHP a aussi un exemple de fonctions pour des expressions POSIX, je
crois qu'il s'agit des ERE.
Enfin, je fais suivre la discussion vers fr.comp.lang.regexp.
P.-S. : Cyrille, tes lignes sont trop longues. Tu ne t'en rends pas
compte à cause du format flowed, mais tu devrais remettre la limite à
72 caractères (ça ne changera rien pour toi mais ce sera mieux pour les
autres).
pour compliquer un peu la chose, nous avons les BRE et les ERE, BRE pour basic regular expression et ERE pour extended regular expression. regular expression se traduisant en français comme expression rationnelle et non régulière ! les BRE sont utilisées par grep, ed et sed. les ERE par egrep et awk essentiellement. le shell (et find) utilise, lui, des patterns, autrement dit, des expressions shell, je ne connais pas d'autre traduction :( direction le jargon français ?
les grosses différences sont :
shell ksh BRE ERE * * .* .* ? ? . . [a-z] idem idem idem +(?) .{1,} .+ ?(?) .{0,1} .? .{1,3} ?{1,3} @(x|y) (x|y) !(x|y)
ksh == bash + shopt -s extglob
Merci pour ce bref résumé.
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression...
« perl compatible regular expression » : il s'agit d'un sur-ensemble des expressions rationnelles de Perl 5.
qui permettent de faire des truc vraiment barbares et incompréhensibles, à la perl, quoi :-)
;-)
Je signale au passage que le JavaScript actuellement implémenté dans la plupart des navigateurs web (ECMA-262 édition 3) utilise les expressions rationnelles de Perl 5, alors que PHP dispose d'un ensemble de fonctions PCRE. PHP a aussi un exemple de fonctions pour des expressions POSIX, je crois qu'il s'agit des ERE.
Enfin, je fais suivre la discussion vers fr.comp.lang.regexp.
P.-S. : Cyrille, tes lignes sont trop longues. Tu ne t'en rends pas compte à cause du format flowed, mais tu devrais remettre la limite à 72 caractères (ça ne changera rien pour toi mais ce sera mieux pour les autres).
Cordialement, -- Olivier Miakinen
Vincent Verdon
Bonsoir,
et merci pour les précisions que vous apportez.
Olivier Miakinen a écrit :
[Copie et suivi vers fr.comp.lang.regexp]
Le 04/11/2009 23:55, Cyrille Lefevre a écrit :
pour compliquer un peu la chose, nous avons les BRE et les ERE, BRE pour basic regular expression et ERE pour extended regular expression. regular expression se traduisant en français comme expression rationnelle et non régulière ! les BRE sont utilisées par grep, ed et sed. les ERE par egrep et awk essentiellement.
Enfin grep -E et sed -r permet d'utiliser les expressions régulières étendues... pour simplifier encore un peu les choses !
le shell (et find) utilise, lui, des patterns, autrement dit, des expressions shell, je ne connais pas d'autre traduction :( direction le jargon français ?
les grosses différences sont :
shell ksh BRE ERE * * .* .* ? ? . . [a-z] idem idem idem +(?) .{1,} .+ ?(?) .{0,1} .? .{1,3} ?{1,3} @(x|y) (x|y) !(x|y)
ksh == bash + shopt -s extglob
Merci pour ce bref résumé.
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression...
« perl compatible regular expression » : il s'agit d'un sur-ensemble des expressions rationnelles de Perl 5.
qui permettent de faire des truc vraiment barbares et incompréhensibles, à la perl, quoi :-)
;-)
Je signale au passage que le JavaScript actuellement implémenté dans la plupart des navigateurs web (ECMA-262 édition 3) utilise les expressions rationnelles de Perl 5, alors que PHP dispose d'un ensemble de fonctions PCRE. PHP a aussi un exemple de fonctions pour des expressions POSIX, je crois qu'il s'agit des ERE.
Enfin, je fais suivre la discussion vers fr.comp.lang.regexp.
P.-S. : Cyrille, tes lignes sont trop longues. Tu ne t'en rends pas compte à cause du format flowed, mais tu devrais remettre la limite à 72 caractères (ça ne changera rien pour toi mais ce sera mieux pour les autres).
Cordialement,
Amicalement, Vincent Verdon
Bonsoir,
et merci pour les précisions que vous apportez.
Olivier Miakinen a écrit :
[Copie et suivi vers fr.comp.lang.regexp]
Le 04/11/2009 23:55, Cyrille Lefevre a écrit :
pour compliquer un peu la chose, nous avons les BRE et les ERE,
BRE pour basic regular expression et ERE pour extended regular expression.
regular expression se traduisant en français comme expression rationnelle et non régulière !
les BRE sont utilisées par grep, ed et sed.
les ERE par egrep et awk essentiellement.
Enfin grep -E et sed -r permet d'utiliser les expressions régulières
étendues... pour simplifier encore un peu les choses !
le shell (et find) utilise, lui, des patterns, autrement dit, des expressions shell,
je ne connais pas d'autre traduction :( direction le jargon français ?
les grosses différences sont :
shell ksh BRE ERE
* * .* .*
? ? . .
[a-z] idem idem idem
+(?) .{1,} .+
?(?) .{0,1} .?
.{1,3} ?{1,3}
@(x|y) (x|y)
!(x|y)
ksh == bash + shopt -s extglob
Merci pour ce bref résumé.
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression...
« perl compatible regular expression » : il s'agit d'un sur-ensemble des
expressions rationnelles de Perl 5.
qui permettent de faire des truc vraiment barbares et incompréhensibles, à la perl, quoi :-)
;-)
Je signale au passage que le JavaScript actuellement implémenté dans la
plupart des navigateurs web (ECMA-262 édition 3) utilise les expressions
rationnelles de Perl 5, alors que PHP dispose d'un ensemble de fonctions
PCRE. PHP a aussi un exemple de fonctions pour des expressions POSIX, je
crois qu'il s'agit des ERE.
Enfin, je fais suivre la discussion vers fr.comp.lang.regexp.
P.-S. : Cyrille, tes lignes sont trop longues. Tu ne t'en rends pas
compte à cause du format flowed, mais tu devrais remettre la limite à
72 caractères (ça ne changera rien pour toi mais ce sera mieux pour les
autres).
pour compliquer un peu la chose, nous avons les BRE et les ERE, BRE pour basic regular expression et ERE pour extended regular expression. regular expression se traduisant en français comme expression rationnelle et non régulière ! les BRE sont utilisées par grep, ed et sed. les ERE par egrep et awk essentiellement.
Enfin grep -E et sed -r permet d'utiliser les expressions régulières étendues... pour simplifier encore un peu les choses !
le shell (et find) utilise, lui, des patterns, autrement dit, des expressions shell, je ne connais pas d'autre traduction :( direction le jargon français ?
les grosses différences sont :
shell ksh BRE ERE * * .* .* ? ? . . [a-z] idem idem idem +(?) .{1,} .+ ?(?) .{0,1} .? .{1,3} ?{1,3} @(x|y) (x|y) !(x|y)
ksh == bash + shopt -s extglob
Merci pour ce bref résumé.
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression...
« perl compatible regular expression » : il s'agit d'un sur-ensemble des expressions rationnelles de Perl 5.
qui permettent de faire des truc vraiment barbares et incompréhensibles, à la perl, quoi :-)
;-)
Je signale au passage que le JavaScript actuellement implémenté dans la plupart des navigateurs web (ECMA-262 édition 3) utilise les expressions rationnelles de Perl 5, alors que PHP dispose d'un ensemble de fonctions PCRE. PHP a aussi un exemple de fonctions pour des expressions POSIX, je crois qu'il s'agit des ERE.
Enfin, je fais suivre la discussion vers fr.comp.lang.regexp.
P.-S. : Cyrille, tes lignes sont trop longues. Tu ne t'en rends pas compte à cause du format flowed, mais tu devrais remettre la limite à 72 caractères (ça ne changera rien pour toi mais ce sera mieux pour les autres).
Cordialement,
Amicalement, Vincent Verdon
Cyrille Lefevre
Vincent Verdon a écrit :
Enfin grep -E et sed -r permet d'utiliser les expressions régulière s étendues... pour simplifier encore un peu les choses !
egrep == grep -E, ce dernier ne marche pas sur tous les OS, alors qu'egrep oui. sinon, s/sed/GNU &/
P.-S. : Cyrille, tes lignes sont trop longues. Tu ne t'en rends pas
j'vais voir ça...
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Vincent Verdon a écrit :
Enfin grep -E et sed -r permet d'utiliser les expressions régulière s
étendues... pour simplifier encore un peu les choses !
egrep == grep -E, ce dernier ne marche pas sur tous les OS, alors
qu'egrep oui.
sinon, s/sed/GNU &/
P.-S. : Cyrille, tes lignes sont trop longues. Tu ne t'en rends pas
j'vais voir ça...
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
> egrep == grep -E, ce dernier ne marche pas sur tous les OS, alors > qu'egrep oui.
grep -E est standard ; egrep ne l'est plus.
grep -E est une invention de POSIX. egrep existe depuis une trentaine d'années.
-- Christian "naddy" Weisgerber
Stephane CHAZELAS
2009-11-04, 23:55(+01), Cyrille Lefevre: [...]
les grosses différences sont :
shell ksh BRE ERE * * .* .* ? ? . . [a-z] idem idem idem +(?) .{1,} .+ ?(?) .{0,1} .? .{1,3} ?{1,3} @(x|y) (x|y) !(x|y)
ksh == bash + shopt -s extglob
C'est un peu raccourci. Le ksh above, c'est ksh88 ou pdksh, ksh93 en supporte des nouveaux. Et c'est oublier zsh.
zsh a l'option kshglob pour les patterns ksh et extendedglob pour ses patterns etendus.
fnmatch ksh88 ksh93t zsh BRE ERE Perl * * * * .* .* .* ? ? ? ? . . . [a-z] idem idem idem idem idem idem +(?) +(?) ?## .{1,} .+ .+ ?(?) ?(?) (?|) .{0,1} .? .? {1,3}(?) .{1,3} .{1,3} .{1,3} @(x|y) @(x|y) (x|y) (x|y) (x|y) !(x|y) !(x|y) ^(x|y) (?!x|y) (x but not y) x~y (?!y)x (nested pair match) %({}Q"E) possible (non-greedy) ~(-g:*) ?# .*? (decimal number match) <1-12> (case insensitive) ~(i:a) (#i)a (?i:a) (2 errors allowed) (#a2)xxxx
ksh reconnait aussi plusieurs formes de regexps (dont son implementation de pcre) et zsh supporte des "globbing qualifiers" qui permettent de selectionner des fichiers selon d'autres attributs que le nom (taille, date de modification, type...) et les pcre par un module.
Comme toujours pour ksh, la doc est incomplete et difficile a trouver.
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression... qui permettent de faire des truc vraiment barbare et incompréhensible, à la perl, quoi :-)
???
Les regexp perl (ou à la perl) ont tendance a devenir la norme de nos jours (ruby, ksh, php, TCL...)
-- Stéphane
2009-11-04, 23:55(+01), Cyrille Lefevre:
[...]
les grosses différences sont :
shell ksh BRE ERE
* * .* .*
? ? . .
[a-z] idem idem idem
+(?) .{1,} .+
?(?) .{0,1} .?
.{1,3} ?{1,3}
@(x|y) (x|y)
!(x|y)
ksh == bash + shopt -s extglob
C'est un peu raccourci. Le ksh above, c'est ksh88 ou pdksh,
ksh93 en supporte des nouveaux. Et c'est oublier zsh.
zsh a l'option kshglob pour les patterns ksh et extendedglob
pour ses patterns etendus.
fnmatch ksh88 ksh93t zsh BRE ERE Perl
* * * * .* .* .*
? ? ? ? . . .
[a-z] idem idem idem idem idem idem
+(?) +(?) ?## .{1,} .+ .+
?(?) ?(?) (?|) .{0,1} .? .?
{1,3}(?) .{1,3} .{1,3} .{1,3}
@(x|y) @(x|y) (x|y) (x|y) (x|y)
!(x|y) !(x|y) ^(x|y) (?!x|y)
(x but not y) x~y (?!y)x
(nested pair match) %({}Q"E) possible
(non-greedy) ~(-g:*) ?# .*?
(decimal number match) <1-12>
(case insensitive) ~(i:a) (#i)a (?i:a)
(2 errors allowed) (#a2)xxxx
ksh reconnait aussi plusieurs formes de regexps (dont son
implementation de pcre) et zsh supporte des "globbing
qualifiers" qui permettent de selectionner des fichiers selon
d'autres attributs que le nom (taille, date de modification,
type...) et les pcre par un module.
Comme toujours pour ksh, la doc est incomplete et difficile a
trouver.
cela sans compter sur les PCRE qui viennent de perl pour perl
je sais pas quoi regular expression... qui permettent de faire
des truc vraiment barbare et incompréhensible, à la perl, quoi
:-)
???
Les regexp perl (ou à la perl) ont tendance a devenir la norme
de nos jours (ruby, ksh, php, TCL...)
shell ksh BRE ERE * * .* .* ? ? . . [a-z] idem idem idem +(?) .{1,} .+ ?(?) .{0,1} .? .{1,3} ?{1,3} @(x|y) (x|y) !(x|y)
ksh == bash + shopt -s extglob
C'est un peu raccourci. Le ksh above, c'est ksh88 ou pdksh, ksh93 en supporte des nouveaux. Et c'est oublier zsh.
zsh a l'option kshglob pour les patterns ksh et extendedglob pour ses patterns etendus.
fnmatch ksh88 ksh93t zsh BRE ERE Perl * * * * .* .* .* ? ? ? ? . . . [a-z] idem idem idem idem idem idem +(?) +(?) ?## .{1,} .+ .+ ?(?) ?(?) (?|) .{0,1} .? .? {1,3}(?) .{1,3} .{1,3} .{1,3} @(x|y) @(x|y) (x|y) (x|y) (x|y) !(x|y) !(x|y) ^(x|y) (?!x|y) (x but not y) x~y (?!y)x (nested pair match) %({}Q"E) possible (non-greedy) ~(-g:*) ?# .*? (decimal number match) <1-12> (case insensitive) ~(i:a) (#i)a (?i:a) (2 errors allowed) (#a2)xxxx
ksh reconnait aussi plusieurs formes de regexps (dont son implementation de pcre) et zsh supporte des "globbing qualifiers" qui permettent de selectionner des fichiers selon d'autres attributs que le nom (taille, date de modification, type...) et les pcre par un module.
Comme toujours pour ksh, la doc est incomplete et difficile a trouver.
cela sans compter sur les PCRE qui viennent de perl pour perl je sais pas quoi regular expression... qui permettent de faire des truc vraiment barbare et incompréhensible, à la perl, quoi :-)
???
Les regexp perl (ou à la perl) ont tendance a devenir la norme de nos jours (ruby, ksh, php, TCL...)
-- Stéphane
Cyrille Lefevre
Christian Weisgerber a écrit :
Nicolas George <nicolas$ wrote:
egrep == grep -E, ce dernier ne marche pas sur tous les OS, alors qu'egrep oui.
grep -E est standard ; egrep ne l'est plus.
grep -E est une invention de POSIX. egrep existe depuis une trentaine d'années.
tu me l'enlèves du clavier :-)
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Christian Weisgerber a écrit :
Nicolas George <nicolas$george@salle-s.org> wrote:
egrep == grep -E, ce dernier ne marche pas sur tous les OS, alors
qu'egrep oui.
grep -E est standard ; egrep ne l'est plus.
grep -E est une invention de POSIX. egrep existe depuis une trentaine
d'années.
tu me l'enlèves du clavier :-)
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
