Syndiquer le contenu
Mis à jour : il y a 10 heures 43 min

Revue de presse de l'April pour la semaine 5 de l'année 2016

9 février, 2016 - 10:52

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

[cio-online.com] Édito: l'abus de propriété intellectuelle nuit à la propriété intellectuelle

Par Bertrand Lemaire, le vendredi 5 février 2016. Extrait:

Les conflits se multiplient entre éditeurs de logiciels et entreprises utilisatrices, notamment autour des audits de licences. Mais, en fait, il n'y a rien de neuf sous le soleil: la rapacité justifiée par la propriété intellectuelle veut réduire à néant une autre propriété intellectuelle, celle des clients utilisateurs.

Lien vers l'article original: http://www.cio-online.com/actualites/lire-edito%A0-l-abus-de-propriete-intellectuelle-nuit-a-la-propriete-intellectuelle-8210.html

[LeMonde.fr] Le Parlement européen veut reprendre la main sur le TiSA, l’autre grand traité qui effraie

Par Maxime Vaudano, le jeudi 4 février 2016. Extrait:

Dans l’univers très anxiogène des grands accords commerciaux négociés derrière des portes closes, le traité transatlantique Tafta/TTIP en préparation entre l’Europe et les Etats-Unis occupe depuis bientôt trois ans le devant de la scène de notre côté de l’Atlantique – quand les Américains s’intéressent davantage au traité transpacifique, officiellement signé le 4 février 2016.

Lien vers l'article original: http://transatlantique.blog.lemonde.fr/2016/02/04/le-parlement-europeen-veut-reprendre-la-main-sur-le-tisa-lautre-grand-traite-qui-effraie

[ouest-france.fr] Il donne accès à une informatique plus éthique

Par Anne-Emmanuelle Lambert, le mercredi 3 février 2016. Extrait:

Depuis septembre, Nicolas Barteau, un Alençonnais de 36 ans, est entrepreneur salarié de la coopérative d'activités et d'emplois Crescendo, basée à Flers. Son boulot: animateur numérique spécialisé dans les logiciels libres.

Lien vers l'article original: http://www.ouest-france.fr/normandie/alencon-61000/il-donne-acces-une-informatique-plus-ethique-4017462

[ZDNet France] Lancement de l'Open Source School

Par Thierry Noisette, le mercredi 3 février 2016. Extrait:

Smile et l'EPSI lancent l'OSS, école d'enseignement supérieur et de formation continue dans l'open source, avec une aide d'Etat de 1,4 million comme investissement d'avenir.

Lien vers l'article original: http://www.zdnet.fr/actualites/lancement-de-l-open-source-school-ecole-superieure-pour-le-logiciel-libre-soutenue-par-le-cnll-39832062.htm

Et aussi:

[L'Express.fr] Partenariat entre Microsoft et l'Éducation nationale: bugs en vue?

Par Sandrine Chesnel, le mercredi 3 février 2016. Extrait:

Un collectif d'associations et entreprises du numérique a déposé un recours auprès du ministère de l'Education nationale pour demander l'annulation d'un partenariat signé en novembre avec Microsoft. Un accord accusé d'illégalité.

Lien vers l'article original: http://www.lexpress.fr/education/partenariat-entre-microsoft-et-l-education-nationale-bugs-en-vue_1759758.html

Et aussi:

Voir aussi:

[rts.ch] "L'iPhone d'Apple est un ordinateur-prison", selon le père du logiciel libre

Par Delphine Gendre, le mardi 2 février 2016. Extrait:

Lors de son passage à Fribourg lundi, le pape du logiciel libre Richard Stallman a accordé un entretien à la RTS. L'Américain de 63 ans a notamment souligné le côté intrusif des logiciels standards.

Lien vers l'article original: http://www.rts.ch/info/sciences-tech/7463886--l-iphone-d-apple-est-un-ordinateur-prison-selon-le-pere-du-logiciel-libre.html

Et aussi:

[Next INpact] Le registre gouvernemental de lobbyistes prend forme

Par Xavier Berne, le mardi 2 février 2016. Extrait:

Annoncé il y a plus d’un an par François Hollande, le registre gouvernemental de lobbyistes devrait prendre forme dans le projet de loi qui sera porté dans quelques semaines devant le Parlement par Michel Sapin. Selon une première version du texte consultée par Mediapart, le dispositif serait cependant largement perfectible.

Lien vers l'article original: http://www.nextinpact.com/news/98331-le-registre-gouvernemental-lobbyistes-prend-forme.htm

Télécharger ce contenu au format Epub

Lire les commentaires

Cinq ans de projets libres : bilan et retour d'expérience sur la contribution

8 février, 2016 - 12:50

Voilà 5 ans que je produis du logiciel libre. J'ai pris l'habitude de publier chaque année mon retour d'expérience sur ce sujet. J'ai parlé de mes premiers pas, de mes doutes, de ce que j'ai appris sur le code, des présentations publiques, de la communauté et enfin de l'impact du logiciel libre sur l'entreprise. C'est déjà un bon tour de la question.

Sommaire

Voilà 5 ans que je produis du logiciel libre. J'ai pris l'habitude de publier chaque année mon retour d'expérience sur ce sujet. J'ai parlé de mes premiers pas, de mes doutes, de ce que j'ai appris sur le code, des présentations publiques, de la communauté et enfin de l'impact du logiciel libre sur l'entreprise. C'est déjà un bon tour de la question. Alors qu'est ce qui ferait un bon sujet pour cette année ? Et bien je vais simplement vous parler de la contribution. C'est l'essence du projet libre, je ne pouvais passer à côté. À travers cet article, je vais donc vous raconter ce que j'ai ressenti en étant des deux côtés de la barrière. Mais, avant de rentrer plus dans les détails, je vous donne le contexte avec un résumé de mes aventures de l'année passée !

Ce que j'ai fait

J'ai encore beaucoup codé et principalement en Coffeescript pour le navigateur et le serveur (Node.js). Je voulais développer mieux et essayer d'autres langages mais je n'y suis pas arrivé. J'ai beaucoup travaillé dans l'urgence et n'ai pas testé de nouveaux outils.

J'ai surtout focalisé mes efforts sur Cozy. En effet, le projet a pris de l'ampleur. La communauté s'est beaucoup développée. J'ai aussi plus de collègues. Autre fait notable, maintenant je travaille non seulement avec des gens très compétents mais aussi avec des personnalités du milieu ! Parmi eux nous trouvons Tristan Nitot qui a notamment fondé Mozilla Europe, et Bruno Michel qui, entre autres choses, a refait et maintient LinuxFr.org. J'ai donc évolué dans un environnement très stimulant et instructif.

Mais surtout cette année, chez Cozy, nous avons eu à gérer beaucoup de contributions tant internes (des collègues) qu'externes. D'un côté l'équipe Cozy s'est affirmée et a grandi. De l'autre, de nombreuses personnes sont venues contribuer. L'impact n'est donc pas négligeable… Car faire les bonnes choses pour que les gens travaillent bien en équipe est difficile. Mais bien intégrer des contributions diverses et aléatoires l'est encore plus (heureusement que je n'étais pas seul pour y faire face). Malgré ça j'ai quand même pu contribuer à droite et à gauche. Dans la suite, je vais donc vous faire part de comment j'ai vécu l'expérience en tant que contributeur et intégrateur de contributions.

Contribuer Faire un rapport de bug

C'est l'action de transmettre la description d'un bug que l'on a rencontré aux auteurs du logiciel. C'est un acte qui parait anodin mais qui requiert d'être bien fait pour être productif. En effet, si le message rédigé n'est pas compréhensible, il n'est pas traitable. Rédiger un rapport de bug demande de la rigueur sur la rédaction. Cela demande aussi de bien décrire le contexte dans lequel le bug se produit.
J'en ai peu rédigé mais j'étais, à chaque fois, content de le faire. Par contre, j'ai parfois été un peu déçu par les réponses reçues. En effet, les réactions des développeurs sont diverses : dans certains cas, les demandes sont ignorées ou fermées un peu brutalement (les développeurs ont vite fait de mettre ça sur le dos d'une dépendance). Heureusement elles peuvent être bien reçues et traitées. On est alors remercié, ce qui est plutôt sympa.

Exemple : Voici un rapport de bug que j'ai rédigé. L'interaction est intéressante. On me demande de rédiger un test en échec lié à mon bug. Un autre contributeur vient corriger le bug ensuite.

Corriger une documentation

C'est l'action d'ajouter un élément manquant ou de corriger une faute d'orthographe dans une documentation. Encore une fois, cela demande de bien rédiger mais au final cela ne prend pas trop de temps. Ce genre de corrections est toujours bien apprécié et accepté. C'est vraiment un bon moyen de commencer à contribuer à un projet.

Exemple : Là je corrige une documentation. Cela intervient après une discussion pour en savoir plus sur l'état du projet. Le mainteneur intègre vite la modification et me remercie.

Faire une correction de bug

Corriger un bug ne requiert pas de comprendre toute l'architecture de l'application. Ce qui est consommateur de temps c'est de s'assurer que les tests automatiques du projet fonctionnent toujours et d'en ajouter s'il en manque. Enfin, il faut bien commenter sa modification. Généralement cela se passe bien.
Attention, assurez-vous aussi que personne ne travaille déjà sur ce bug avant. Pour cela vous pouvez en discuter sur le ticket concerné.

Je n'ai malheureusement pas retrouvé d'exemple à ce sujet.

Ajouter une fonctionnalité

Je ne me suis lancé là-dedans qu'une fois et, malheureusement, l'expérience fut assez mauvaise. Ayant beaucoup utilisé le framework Express JS pour Node.js, je me suis dit qu'il serait intéressant d'y contribuer. J'ai donc choisi une demande d'amélioration simple de leur côté. Cela m'a demandé beaucoup de boulot. J'ai d'abord dû bien comprendre la demande et me documenter sur la fonctionnalité demandée (permettre au framework d'alimenter un traceur à des fins de debug).
J'ai posé de nombreuses questions pour être sûr que je n'étais pas à côté de la plaque. Ensuite j'ai dû comprendre une partie du code du framework. Enfin j'ai pu développer la fonctionnalité demandée. Au début j'ai eu du feedback intéressant du mainteneur principal sur ce que j'avais réalisé. Mais ensuite d'autres contributeurs sont venus donner leur avis. Pertinents mais un peu perfectionnistes à mon goût. J'ai quand même joué le jeu et ai subi plusieurs allers et retours. Finalement mon code n'a jamais été fusionné.
Conclusion, ajouter une fonctionnalité importante n'est pas toujours bien reçu. Il ne faut pas s'attendre forcément à un retour positif.

Exemple : Pour le projet Express, mon ajout aboutira à une discussion de 49 commentaires sans fusion au final. À l'inverse voici une modification bien reçue par l'auteur de Kresus, une application de gestion bancaire. Cette fois l'auteur est très content !

Faire une présentation sur une techno pas à soi.

J'ai fait deux présentations concernant la base de données dans le navigateur PouchDB. Les auteurs étaient très contents. Je me suis senti utile : c'était motivant pour eux et ça faisait découvrir une belle techno à plein de gens.

Exemple : Voilà la vidéo de ma présentation aux Human talks sur PouchDB. Les auteurs ont aussi manifesté leur joie sur les réseaux sociaux suite à ma contribution sur cette présentation faite à DotJS.

Faire un don

Des fois le moyen le plus simple d'aider est de faire un don. Cela peut permettre à un groupe ou organisation d'améliorer ses conditions de travail ou les services qu'il propose. Ainsi j'ai aidé l'April et le projet Salut à Toi. J'ai encore vu des gens contents !

Bénévolat

J'ai fait un peu de bénévolat au FOSDEM. Cela consistait à réaliser des actions simples comme m'occuper du vestiaire. C'est une contribution qui a permis de rendre l'événement un peu mieux. En plus, c'est à la portée de tout le monde. Pareil que pour le talk, le niveau de satisfaction était élevé ! C'est le genre de contributions auxquelles on ne pense pas toujours mais bien utile. Les gens de l'événement m'ont chaleureusement remercié et j'ai gagné du karma et un tee-shirt FOSDEM Volunteer.

.

C'est fini pour la partie contributeur. Passons maintenant à la partie recevoir une contribution. Mais avant ça, je voulais décerner une mention spéciale au projet PouchDB. L'accueil des auteurs et leur rigueur m'ont bien motivé !

Recevoir une contribution Recevoir une traduction

La traduction est une belle contribution car elle permet à des gens non techniques de participer. C'est très stimulant d'en recevoir une. Bien la gérer par contre n'est pas évident. Car lorsque les messages de l'application bougent, les traductions sont perdues. De plus les gens non techniques ne sont pas familiers des outils de gestion de version. Il faut donc souvent se tourner vers des outils en ligne dédiés à la traduction collaborative.

Ce que je fais : je remercie la personne et la renvoie vers Transifex, la plateforme que nous utilisons chez Cozy. Utiliser un outil dédié est beaucoup plus pratique que demander aux gens d'utiliser Git et Github.

Recevoir un rapport de bug

Une autre contribution à la portée de tous… Enfin de ceux familiers avec les outils de gestion de tickets ! C'est très satisfaisant d'en recevoir une car elle vous démontre que d'autres personnes se servent ou veulent se servir de votre application. Toutefois le rapport de bug se doit d'être bien rédigé pour ne pas faire perdre trop de temps en aller et retours. Recevoir beaucoup de rapports de bugs peut s'avérer oppressant.

Ce que je fais : je remercie la personne. Ensuite, je demande des détails si nécessaire. Lorsque le travail est terminé et livré, je vérifie avec la personne que le bug est bien résolu. Si c'est ok ou si je n'ai pas de nouvelles dans les semaines qui suivent je ferme le bug.

Exemple: Un rapport de bug simple et bien traité (remerciements et confirmation inclus).

Recevoir une demande d'amélioration, un feedback

De même que précédemment, c'est très satisfaisant et requiert au contributeur de maitriser un outil de gestion de tickets. Toutefois ces demandes sont généralement difficiles à prendre en compte. La liste des bugs et des idées est souvent déjà suffisante. Là où ça devient très parlant, c'est quand la demande se répète, on comprend donc qu'il faut faire quelque chose.

Ce que je fais : je remercie la personne et laisse le ticket ouvert jusqu'à implémentation de la fonctionnalité.
Plus récemment j'ai demandé aux contributeurs de plussoyer une demande si elle leur plait. C'est un bon moyen d'évaluer la popularité de celle-ci.

Exemple : Voilà une simple demande d'amélioration que j'ai traitée pour la lib request-json. Par contre des fois la demande est automatiquement fermée par Github suite à l'intégration du correctif, ce qui n'est pas très sympa pour le contributeur.

Recevoir une correction de bug

C'est une très bonne contribution à recevoir. Par contre, si le correctif n'est pas parfait, c'est délicat de demander d'améliorer des modifications (ajout de commentaires ou de tests par exemple). Heureusement, les contributeurs sont assez contents de bien faire le travail, donc on peut être exigeant. Une fois intégré, c'est une petite victoire. Le bug a été corrigé sans votre intervention et la communauté du logiciel se renforce !

Ce que je fais : Suite aux remerciements, je fais une revue du correctif et fusionne les changements si tout est ok. Je rajoute le nom du contributeur à la liste des contributeurs (quand j'y pense).

Exemple : Ici je remercie le contributeur et intègre ses changements. Il apparait ensuite dans liste des contributeurs.
Certains associent systématiquement une modification à un ticket. Même si je ne le fais pas, il faut bien admettre que c'est une bonne pratique.

Recevoir une correction de documentation

Très agréable aussi, ces corrections se valident très rapidement et rendent le projet plus crédible.

Ce que je fais : Je vérifie, je remercie, j'intègre des modifications et rajoute à la liste des contributeurs.

Exemple : Ici j'intègre des corrections d'anglais sur la doc de Cozy. Je montre ma joie et j'intègre.

Recevoir une fonctionnalité

Cette contribution est plus délicate. En effet d'un côté c'est très plaisant de la recevoir. De l'autre l'implémentation n'est pas toujours satisfaisante. En effet, pour le contributeur c'est difficile de coder dans le style du ou des mainteneurs principaux et de bien faire l'implémentation. Par contre si c'est bien fait, ce n'est que du bonheur !

Ce que je fais : Ma réaction est très variable. Ça n'arrive pas si souvent et c'est vraiment du cas par cas. Si j'ai une recommandation, c'est de bien expliquer dans un ticket avant de coder ce que vous comptez faire.
Pour les contributions mal fichues, je demande au contributeur de corriger. Pour les détails, je les prends à ma charge pour ne pas le décourager. Intégrer ce genre de modifications prend du temps dans tous les cas.

Exemple : Voici un ajout de fonctionnalité qui a demandé du boulot aux deux parties. Le code ne nous convenait pas tant dans l'architecture que dans le style. Nous avons fait la revue de code pour apprendre le style attendu. Ensuite nous avons aidé le contributeur à revoir son architecture pour qu'elle nous satisfasse.

Recevoir beaucoup de code

Cela n'arrive pas souvent mais quand c'est le cas, il n'y a pas à dire, on est très content ! Malheureusement, parfois ça devient difficile. Car intégrer toutes les modifications impose un certain rythme qui n'est pas facile à tenir.

Ce que je fais : ce n'est arrivé qu'une fois et j'ai fini par refuser les modifications qui m'étaient envoyées. Au début je faisais de mon mieux pour tout intégrer et faire en sorte que ça respecte la philosophie du projet. Mais je n'ai pas pu tenir le rythme. J'ai fini par fermer une demande de modifications. Le code n'était pas commenté, les commits étaient peu clairs et je n'avais plus le temps de remettre le tout au propre. Le contributeur s'est vexé et a arrêté de faire des modifications.

Exemple : Ce cas m'est arrivé pour le projet expérimental Cozy Light. Après de nombreux échanges, j'ai refusé cette modification. Je dois avouer que je ne savais pas du tout comment gérer la situation. Et l'effet s'est bien ressenti. Après ça le contributeur s'est vexé et a arrêté de contribuer.

Voir une app se développer sur la plateforme

Celle-ci est le genre de contribution qui n'existe pas pour tous les projets. Au mieux, les projets proposent au contributeur de faire des greffons. Mais le projet Cozy permet de réaliser des applications complètes. Pour les plateformes, c'est un peu la contribution ultime. En effet on voit un autre projet se développer au dessus d'un autre. Ensuite, le nouveau projet se constitue à son tour sa propre communauté !

Exemple : L'application Kresus est partie d'un fork d'une app existante. Un an après, voici le sujet Kresus sur le forum de Cozy. L'auteur y annonce ses nouveautés. Le sujet engendre une discussion de près de 200 messages. Tout le monde est content !

Voir un contributeur en aider un autre

Là on voit la communauté du projet qu'on a initié devenir autonome. C'est un peu l'extase pour le mainteneur !

Exemple : un contributeur se pose une question sur le processus d'installation. Un autre vient lui fournir une explication.

Recevoir des encouragements

Cela arrive par courriel, via le forum ou via IRC. Encore une fois c'est génial de recevoir ce type de message. Ça coûte pas grand chose, donc ne vous retenez pas si vous aimez bien un projet ! J'en ai encore reçu un hier. C'est très encourageant.

Conclusion

Et voilà, le bilan se termine ici. La contribution est le moment le plus exaltant du projet libre. Les esprits se connectent pour réaliser un travail collaboratif. La magie se crée. Quand j'ai commencé à écrire du code libre, ce qui m'attirait le plus était de faire les choses enfin proprement et à ma manière. Aujourd'hui, ce qui me motive le plus c'est de voir le projet vivre sa vie et d'observer les interactions des contributeurs.

L'acte de contribuer permet de faire avancer significativement les projets que vous aimez. Les mainteneurs gagnent du temps, sont aiguillés dans la bonne direction et sont plus motivés. C'est aussi l'occasion pour vous de progresser techniquement et sur le plan rédactionnel. Bref, c'est une bonne source de points de karma à portée de main. N'hésitez pas à en abuser !

Ce bilan est aussi l'occasion de clore un premier cycle exploratoire du monde du logiciel libre. J'ai couvert les thèmes principaux que sont la mise en place d'un projet, son évangélisation, le rapport à la communauté, comment il s'intègre dans une entreprise et enfin comment se vit une contribution.
Pour les cinq prochaines années, rien est décidé mais j'ai déjà quelques idées. En dehors de continuer à travailler sur Cozy et Newebe, je vais essayer de découvrir d'autres langages (Go et Lua probablement). Et ce en contribuant plutôt qu'en montant un nouveau projet. Une autre chose que j'aimerais bien faire est de tester un développement écrit en Espéranto plutôt qu'en anglais (au moins dans les commentaires). Je n'en dis pas plus pour le moment, car je réserve cette histoire pour un prochain épisode !

Télécharger ce contenu au format Epub

Lire les commentaires

Travailler avec des expressions rationnelles

8 février, 2016 - 08:55

Les expressions rationnelles sont un outil d'analyse de texte par un ordinateur. Elles permettent de décrire des enchaînements de caractères d'une complexité suffisamment grande pour être réellement utiles mais suffisamment faible pour être implémentées efficacement. Elles sont d'une importance capitale pour le théoricien des langages comme pour l'UNIX power-user.

Dans cette dépêche, nous :

  • décrivons brièvement la notion abstraite d'expression rationnelle et recensons les implémentations les plus courantes sur un système Unix ;
  • présentons quelques commandes permettant de rechercher des motifs décrits par une expression rationnelle dans un texte, réécrire des fichiers automatiquement ou transformer et analyser des fichiers structurés automatiquement en utilisant des expressions rationnelles ;
  • montrons comment améliorer votre productivité avec Emacs grâce aux expressions rationnelles.

Dans cette dépêche, nous allons nous pencher sur les expressions rationnelles (souvent nommées abusivement expressions régulières suite à une traduction littérale de regular expression). Elles permettent de représenter formellement un motif de recherche, par exemple : 1 caractère alphabétique majuscule suivi de 4 caractères minuscules, puis 2 chiffres, 1 point à la fin. Les expressions rationnelles représentent un outil puissant pour qui sait les utiliser à bon escient mais nécessitent une phase d'apprentissage non négligeable. La diversité des moteurs et des syntaxes n'aide pas non plus à leur simplicité, et les confusions entre les différents outils peuvent parfois donner des résultats surprenants.

    Sommaire

    Source: original en VO XKCD, traduction en VF

    Description abstraite et implémentations principales

    Les expressions rationnelles sont souvent utilisées comme brique de l'analyse des textes, pour faire de l'analyse lexicale. Elles sont issues des théories mathématiques des langages formels.

    Le concept ayant montré sa pertinence, il faut faire face à une richesse des implémentations : POSIX, puis chaque Unix à sa version, GNU, FreeBSD, puis Perl et Emacs pour les plus répandues. Certaines apportent des extensions (sucre syntaxique +, répétitions, groupes, et backtracking).

    Wikipédia fournit divers exemples illustratifs. Pour citer quelques exemples variés ici :

    • recherche de motif avec grep pour avoir un filtre pour sélectionner des lignes, pour identifier des fichiers, pour sélectionner des logs à une certaine date ou pour rechercher dans les pages de manuel, etc.
    • avec sed, transformation de logs en format Apache en format tabulaire, transformation de la sortie de docker ps, etc.
    • dans Emacs, mettre en valeur un motif dans du code pour une revue ou pour l'édition, extraire des listes d'un fichier avec re-search, etc.
    Les expressions rationnelles Posix basiques

    Les Expressions Rationelles Posix génèrent des machines à état fini déterministe. Elle ne sont ainsi pas capables de faire des retours en arrière.

    La commande grep

    Le premier usage des expressions rationnelles pour les utilisateurs de systèmes basés sur Linux ou Unix est en général la commande grep, qui permet de trouver toutes les lignes correspondant à une expression rationnelle. La syntaxe de la commande grep est simplement :

    grep <options> <expression rationnelle> <liste de fichiers>

    Pour les exemples ci-dessous, nous ferons des recherches dans le fichier french d'une Debian stable (paquet wfrench qui amène le fichier /usr/share/dict/french, informations de licence), ce fichier contenant la liste des mots de la langue française à raison d'un mot par ligne

    Dans une expression rationnelle, la première règle est que chaque caractère représente lui-même, par exemple l'expression rationnelle « rationnelles » correspond à « toute ligne contenant un r, suivi d'un a, suivi d'un t, suivi d'un i, suivi d'un o, suivi d'un n, suivi d'un autre n, suivi d'un e, suivi d'un l, suivi d'un autre l, suivi d'un e, suivi d'un s » :

    Chaque caractère ne représente pas vraiment lui-même, il existe des exceptions avec des méta-caractères qui décrivent autre chose qu'eux-mêmes. Un des plus utilisés de ces méta-caractères est le point, qui signifie « un caractère quelconque », par exemple l'expression rationnelle « rationnelle. » correspond à « toute ligne contenant un r, suivi d'un a, suivi d'un t, suivi d'un i, suivi d'un o, suivi d'un n, suivi d'un autre n, suivi d'un e, suivi d'un l, suivi d'un autre l, suivi d'un e, suivi d'un caractère quelconque » :

    Le problème des métacaractères est qu'on peut vouloir chercher du texte les contenant, par exemple dans notre dictionnaire il y a des abréviations terminant par un point. Pour qu'un métacaractère ne soit pas interprété, il faut le précéder d'un « \ », par exemple « \. » représente le caractère point. On peut alors s'amuser à chercher les abréviations d'au moins six caractères, en les décrivant comme « un caractère quelconque, suivi d'un autre caractère quelconque, suivi d'un troisième caractère quelconque, suivi d'un quatrième caractère quelconque, suivi d'un cinquième caractère quelconque, suivi d'un sixième caractère quelconque, suivi d'un point » :

    On remarquera que le point lui-même est un caractère quelconque.

    Un autre métacaractère utile est le crochet, qui permet de décrire un caractère pouvant correspondre à plusieurs valeurs, par exemple une voyelle non accentuée peut être représentée par « [aeiouy] » (qu'on peut lire comme « n'importe quel caractère étant soit un a, soit un e, soit un i, soit un u, soit un y »). Par exemple si vous voulez briller en société en citant des mots comportant 6 voyelles non accentuées à la suite :

    Deux métacaractères particuliers sont utiles entre crochets :

    • le tiret situé entre deux caractères permet de définir une liste de caractères qui se suivent, par exemple « [a-f] » définit « soit un a, soit un b, soit un c, soit un d, soit un e, soit un f »
    • l'accent circonflexe situé au début permet de définir une exclusion de caractères, par exemple « [^aeiouy] définit « un quelconque caractère qui ne soit ni un a, ni un e, ni un i, ni o, ni un u, ni un y ») Ces deux métacaractères sont cumulables, par exemple « [^a-z] » définit « un quelconque caractère qui ne soit pas une lettre », ce qui peut nous permettre de trouver tous les mots qui ont à la suite deux caractères qui ne sont pas des lettres :

    On peut économiser les copier/coller lorsque l'on veut chercher plusieurs fois la même information, en utilisant le symbole « \{min,max\} » qui permet d'indiquer que l'on cherche la présence d'un caractère successivement entre min et max fois, par exemple si vous cherchez les mots contenant deux « q » séparés par 5 à 7 lettres [1] :

    Il est possible avec certaines versions de grep de spécifier un seul chiffre entre accolades :

    • si on cherche exactement X occurrences on indique : « \{x\} »
    • si on cherche de 0 à X occurrences on indique : « \{,x\} »
    • si on cherche au moins X occurrences on indique : « \{x,\} » Ainsi, on pourrait donc abréger la recherche des mots contenant 6 voyelles non accentuées ainsi :

    Si on veut répéter plusieurs caractères au lieu d'un seul, il faut encadrer la recherche avec des « \( \) », Par exemple si vous bloquez dans une grille de mots croisés sur la définition « mot contenant 7 fois à la suite une consonne suivie d'une voyelle » :

    Le contenu trouvé à partir d'une expression entre parenthèses est dit « capturé », cela signifie qu'il est gardé en mémoire et peut être réutilisé dans l'expression rationnelle. La contenu capturé est accessible en utilisant « \1 », « \2 », « \3 », etc. (en général on ne peut pas dépasser \9). Le numéro de capture est défini en comptant le nombre de parenthèses ouvrantes précédant l'expression capturée. Cela permet par exemple de lister les mots contenant un palindrome de 4 lettres :

    On peut encore affiner les recherches en utilisant les ancres, qui permettent de situer où se situe une expression rationnelle dans la ligne :

    • le dollar, lorsqu'il est situé à la fin de l'expression rationnelle, représente la fin de la ligne
    • l'accent circonflexe, lorsqu'il est situé au début de l'expression rationnelle, représente le début de la ligne

    On peut cumuler les deux ancres dans la même expression, par exemple si on veut chercher les vrais palindromes de 4 lettres :

    Pour en terminer avec les expressions rationnelles Posix basiques, il ne reste plus qu'un métacaractère à présenter, qui est l’astérisque. Ce caractère est équivalent à « {0,} ».

    Utiliser dans vi

    VimRegex détaille largement le sujet.

    Extension des expressions rationnelles

    Les extensions rationnelles basiques étant peu lisibles, la norme Posix a évolué pour intégrer les expressions rationnelles étendues, aussi appelées « ERE ».

    grep est mieux avec -E

    Les versions récentes de grep permettent d'utiliser les expressions rationnelles étendues avec l'option -E. Si vous ajoutez l'option -E à grep, vous devez modifier votre expression rationnelle ainsi :

    • \{ et \} deviennent { et }
    • \( et \) deviennent ( et )
    • tous les autres métacaractères (« . », « [ », «  ] », « - », « ^ », « $ », « * », « \1 », etc.) sont inchangés

    Outre cette suppression des « \ » superflus, les ERE apportent trois nouveaux métacaractères. Le premier est « ? » qui est un synonyme de « {0,1} », qui permet par exemple de chercher les palindromes de 4 ou 6 lettres avec une seule expression :

    On dispose aussi de « + » qui est un synonyme de {1,}

    Enfin le dernier métacaractère spécifique aux ERE est le « | » qui permet de séparer plusieurs options :

    Les classes de caractères

    Posix prévoit des classes de caractère, qui sont des notations spécifiques entre crochets. À noter que les classes de caractères sont aussi bien gérées par les expressions rationnelles basiques que étendues (il n'y a donc pas besoin d'utiliser l'option -E pour en bénéficier), mais il existe des implémentations d'expressions rationnelles basiques non compatibles Posix qui ne les acceptent pas.

    Les classes de caractères sont des mots ou abréviations en anglais désignant ce à quoi ils correspondent et encadrés par « [: :] ».

    • [:digit:] : désigne un chiffre décimal (équivalent à [0-9])
    • [:lower:] : désigne une lettre minuscule (équivalent à [a-z])
    • [:upper:] : désigne une lettre majuscule (équivalent à [A-Z])
    • [:alpha:] : désigne une lettre minuscule ou majuscule (équivalent à [A-Za-z])
    • [:alnum:] : désigne une lettre minuscule ou majuscule ou un chiffre (équivalent à [A-Za-z0-9])
    • [:xdigit:] : désigne un chiffre hexadécimal (équivalent à [a-fA-F0-9])
    • [:space:] : désigne un caractère d'espacement (espace, tabulation, retour chariot, etc.)
    • [:blank:] : désigne un espace ou une tabulation horizontale (à ne pas confondre avec [:space:])
    • [:punct:] : désigne à un crochet ou un caractère de la classe suivante : ['!"#$%&()*+,./:;<=>?@^_`{|}~-]
    • [:cntrl:] : désigne un Caractère de contrôle
    • [:print:] : désigne un caractère affichable (ainsi qu'une espace), cette classe est à peu près le contraire de [:cntrl:]
    • [:graph:]: désigne l'ensemble des caractères visibles sauf les espaces, les caractères de contrôle, etc. Équivalent à [\x21-\x7E].
    Pour aller plus loin Attention au GLOB

    Dans les exemples précédents, il était important d'utiliser de simples apostrophes pour éviter l'interprétation de caractères spéciaux par le shell.

    Outils pour tester vos expressions rationnelles

    Plusieurs outils s'offrent à vous pour tester et triturer dans tous les sens vos expressions rationnelles comme par exemple le site Regexpal qui propose notamment de la coloration syntaxique et se veut "temps réel" dans les modifications, ou regex101 permet de tester des expressions rationnelles Python, javascript ou pcre.

    Ne pas toujours utiliser les expressions rationnelles

    Les expressions rationnelles ne sont par exemple pas l'outil idéal pour analyser du XML ou de l'HTML.

    Jouer avec les expressions rationnelles

    Voir la dépêche Regexcrossword : un subtil mélange de sudoku et de mots croisés, à la sauce Regex, ainsi que la chasse au trésor du MIT en 2014, etc.

    Un peu de théorie Les automates finis

    La base théorique des expressions rationnelles se trouve dans la théorie des langages. Notamment elles permettent de décrire les langages rationnels. Elles sont fortement liées aux automates finis.

    Pour illustrer le parallèle nous allons utiliser les caractères et les quantificateurs de base :

    • a qui permet de reconnaitre la lettre a ;
    • ? qui permet de définir un groupe optionnel ;
    • * qui permet de définir un groupe se répétant zéro fois ou plus ;
    • + qui permet de définir un groupe se répétant une fois ou plus.
    Littérature

    [1] avec ça vous allez vraiment briller en société, il faudra juste trouver un moyen d'intégrer ça dans la conversation

    Télécharger ce contenu au format Epub

    Lire les commentaires