Il y a à la fois une interprétation stricte qui est qu'on ne récupère pas une oeuvre soumise au droit d'auteur sans l'accord du propriétaire des droits patrimoniaux... Et il y a une autre interprétation,que j'ai évoquée et à laquelle je me raccrochais (et à laquelle j'aurais aimé pouvoir me raccrocher davantage) qui est que quand on publie un fil RSS, c'est qu'on autorise son exploitation (un peu comme si on publiait un site web et qu'en même temps on ne voulait pas que les gens y viennent).
Tant que cela n'aura pas été jugé, on peut très bien ergoter pour l'une ou pour l'autre. D'autre part, je ne suis pas idiot, même si je préfère largement la seconde interprétation, parce qu'elle correspond à ma sensibilité, je pense qu'un tribunal aura tendance à favoriser la première, plus stricte. Malheureusement.
Comme je l'ai dit, le seul moyen pour régler le problème, c'est que le droit d'exploitation soit clairement précisé dans le fil RSS.
Vraiment je m'interroge sur tes contributions. On dirait que tu es en croisade contre les méchants informaticiens et les violeurs de droit d'auteur qui peuplent l'internet.
Je te remercie pour tes considérations sur le droit d'auteurs, même si tu ne m'apprends plus grand chose, mais à aucun moment je n'ai dit qu'il fallait le baffouer.
Si tu quittais un instant ton habit de super-héros qui défend aveuglement le droit d'auteur, si tu fréquentais un peu les blogs, bref, si tu connaissais un peu le sujet, tu saurais qu'il y a une majorité de bloggeurs qui sont tout à fait satisfait des aggrégateurs en ligne, qui contribuent à leur offrir une meilleure visibilité. Il y a évidemment toujours les autres, qui considèrent cela comme une violation de leur droit d'auteur, et c'est leur droit, et il faut les respecter. Cela, c'est acquis.
Mon propos, c'est qu'il faut justement permettre à chacun des bloggeurs d'établir leurs conditions d'utilisation pour leurs fils RSS, de manière à ce qu'il soit possible de récupérer et de republier les fils RSS de ceux qui l'autorisent (je répète: DE CEUX QUI L'AUTORISENT).
> C'est au contraire quelques informaticiens qui croient pouvoir changer la protection légale ou passer outre jusqu'à qu'on les rappelle explicitement à l'ordre.
Comme c'est charmant. Un complexe de supériorité de ta part sans doute, maintenant que tu as lu en diagonale le code de la propriété intellectuelle ?
Tu es tellement persuadé que tout le monde baffoue le droit d'auteur que tu n'imagines même pas un seul instant que certains bloggeurs VEULENT autoriser la publication de leur contenu, et que ton comportement sclérosé ne contribue qu'à les en empêcher. Merci, on a bien compris qu'on n'avait pas le droit, maintenant ce qu'on voudrait c'est pouvoir avancer un peu dans la bonne direction.
Il n'y a aucune différence fondamentale entre une aggrégateur en ligne et un aggrégateur sur le bureau, dès lors que les billets ne sont accessibles qu'à l'utilisateur.
Les deux récupèrent, stockent, et affichent à leur manière des articles publiés. De la même manière, ces billets ne sont accessibles qu'à leur utilisateur.
Si ton aggrégateur de bureau stockait ses données sur une base de données sur le web, ce serait bien pareil. S'il affichait ses données via une interface web, ça serait tout pareil également. S'il affiche ses données via une interface web avec une base de données distante sur le web, ça reste pareil.
Si tu lis ton lecteur RSS de bureau est un programme Gnome ou KDE (disons basé sur X-Window) qui s'affiche sur ton poste de travail mais qui tourne sur une machine distante quelque part sur le web, est-ce que tu vas considérer que la machine distante fait une publication ? Je suis sûr que non.
Je le répète, il ne s'agit pas d'une publication, il s'agit d'un logiciel privé de lecteur de RSS qui est opéré par un tiers et qui fonctionne sur une interface web.
Alors là je t'arrête immédiatement : tu me fais un très mauvais procès, et tu es vraiment à côté de la plaque.
Outre que le ton que tu emploies est inutilement aggressif et accusateur ("Encore faut'il le vouloir, le veux tu ?" -> inutile de sortir l'arsenal de l'inquisition, je suis justement ici pour poser le problème sur la table, pas pour recevoir une leçon de morale alors que précisément je suis d'accord à 100% sur le nécessaire respect des droits d'auteurs).
D'abord, comme je l'ai dit plus haut, le lien vers la sélection affiche PAR ERREUR les billets sélectionné par l'utilisateur. C'est une rémanence de l'ancien système d'affichage, qui est d'ailleurs corrigé à l'heure où je te parle. C'était le seul point problématique, et tu t'y engoufres comme si tout le site était destiné à la violation du droit d'auteur.
De plus, je maintiens : aucun billet (modulo le bug mentionné, qui est maintenant corrigé) n'est
- ni indexé à mon profit par les moteurs de recherches (les moteurs ne s'enregistrent pas comme utilisateur et n'ont donc pas accès aux billets)
- ni attribué à ouliblog, de quelque manière que ce soit (l'auteur et le site sont systématiquement mentionnés)
- Les fils RSS ne sont PAS visible au public, et il s'agit pas d'une publication,.
Je suis d'autant plus surpris par ta réaction que j'ai déjà discuté des problèmes de droits d'auteurs avec un avocat très remonté contre ouliblog, et qu'après avoir rajouté la restriction d'accès, il a reconnu sans problème qu'il n'y avait plus là de problème légal.
J'ai l'impression que tu me cites une liste exhaustive de griefs accumulés contre je-ne-sais-qui, et que tu cherches à me l'appliquer coûte que coûte, alors que je t'assure qu'à aucun moment je n'ai cherché à transigé sur le droit d'auteur.
Pour conclure:
> Légalement tu es en tort sans aucun doute possible. Tu copies, publies et présente un contenu. Tu casses trois des monopoles accordés à l'auteur quand il créé quelque chose. Pire faisant une extraction systématique et automatique de tout ce qui sort du flux RSS, tu tombes aussi très probablement sur le droit spécifique aux bases de données.
Là tu débloques. Le RSS est précisément fait pour une extraction systématique et automatique. Tu crois que c'est un format destiné à être affiché, comme le HTML ? Absolument pas. Non, le RSS est fait pour les outils d'extraction, c'est son unique but. D'ailleurs, son premier objectif était de pouvoir afficher sur son site le contenu d'un autre site. Je ne sais pas pourquoi tu tiens absolument à m'accuser à tort et à travers, mais c'est très peu pertinent.
Pour être clair, il faut que tu comprennes bien que les billets dans ouliblog ne sont présentés qu'à ses utilisateurs privés, il ne s'agit pas d'une mise à disposition du public, et il ne s'agit pas d'une publication.
Pour répondre au "pire en faisant une extraction systématique et automatique de tout ce qui sort du flux"... je préfère te fournir un extrait du code de la propriété intellectuelle:
Art. L. 342-3. Lorsqu'une base de données est mise à la disposition du public par le titulaire des droits, celui-ci ne peut interdire :
1° L'extraction ou la réutilisation d'une partie non substantielle, appréciée de façon qualitative ou quantitative, du contenu de la base, par la personne qui y a licitement accès ;
2° L'extraction à des fins privées d'une partie qualitativement ou quantitativement substantielle du contenu d'une base de données non électronique sous réserve du respect des droits d'auteur ou des droits voisins sur les oeuvres ou éléments incorporés dans la base.
(Modification issue du projet de loi relatif au droit d’auteur et aux droits voisins dans la société de l’information voté par le Parlement le 30 juin 2006)
Le RSS rentre exactement dans ce cas là: il met à disposition une partie non-substantielle (souvent une vingtaine d'articles) de la base de données du blog.
Je pensais avoir tout vu, mais venir me dire que je pille une base de données parce que je vais récupérer un flux RSS qui est mis à disposition, je crois que ça bat tous les records. Je vais avoir du mal à m'en remettre :-)
>> De cette façon, ouliblog n'est pas attaquable pour contrefaçon.
>Légalement ça ne change rien.
Ho que si, ça change tout. Et si j'ai changé la politique d'affichage de ouliblog pour que les billets ne soit plus accessibles qu'aux utilisateurs, c'est parce que dans ce dernier cas il ne s'agit plus d'une publication strictu sensu, et que ça n'est pas proscrit par la loi.
D'ailleurs pour tout te dire, c'est suite à un échange très intéressant par mail avec un bloggeur juriste (avocat de profession) qui était très à cheval sur son droit d'auteur et qui se plaignait d'ouliblog que nous sommes arrivés à cette conclusion (bon, soyons honnêtes, c'est lui qui y est arrivé). Alors ça n'est pas écrit dans le marbre, mais pour avoir consulté quelques juristes, je suis assez sûr de moi pour dormir tranquille de ce côté là (modulo le bug que tu as repéré et que je vais rapidement corriger).
> C'est effectivement dommage, mais qui a dérappé ? l'auteur ou l'aggrégateur qui n'a pas respecté les désidérata ?
Le problème c'est que le RSS est un format destiné à la syndication, donc à la publication externe de contenu, et que l'utilisation en soi de ce format de publication est une indication de la volonté de l'auteur. On peut ne pas être d'accord avec ça, mais c'est défendable. Si je fabrique des stickers autocollant et que je les distribue, puis-je décemment me plaindre que les gens vont les coller ? Si mon désir en tant qu'auteur est que les gens ne les collent pas, hé bien il suffit de faire des stickers qui ne soit pas auto-collant. Elle a souvent bon dos, la volonté de l'auteur, mais je le répète, quelqu'un qui ne veut pas qu'on affiche son contenu ailleurs que chez lui peut TOUT SIMPLEMENT ne pas publier de fil RSS, auquel cas tout malentendu disparait.
Après, il faut être juste, quand les aggrégateurs ne respectent pas la volonté des auteurs, c'est en général parce que ces derniers n'ont pas de moyen technique pour l'exprimer. Et là, je pense qu'on est tous d'accord, il faudrait vraiment que ça soit, non seulement techniquement possible, mais pratiquement obligatoire dans la norme, d'exprimer les conditions d'utilisation du flux RSS.
Cela dit, publier un fil RSS, c'est quand même faire un acte volontaire de publication dans un format qui s'appelle "Really Simple Syndication", autrement dit dans un format fondamentalement fait pour la syndication. D'ailleurs les sites comme le monde ou libération l'ont très bien compris, puisqu'ils se contentent de ne mettre dans le RSS que ce qui est librement publiable ailleurs, les gens devant aller sur leur site pour lire le contenu.
Pour le champ "copyright", malheureusement non, il n'est pas utilisable. D'abord parce que tout contenu est soumis au droit d'auteur (et au copyright), mais ça n'empêche pas que le contenu soit librement diffusable et publiable. Il n'y a pas de corrélation possible entre ces deux notions, sinon que l'une dépend de l'autre (il faut que je possède le copyright/droit d'auteur pour avoir le droit de définir la licence de publication/distribution sur le contenu).
En tout cas, nous sommes d'accord, il faut que la volonté des auteurs soit respectée, mais il faut *aussi* qu'elle soit clairement apréhendable par les outils: il faut donc un licence systématique et explicite sur le contenu des fils RSS/Atom.
Mais sans être un geek, ce n'est quand même pas demander la lune que de demander aux gens de comprendre ce qu'est un fil rss, surtout s'ils en installent un.
Voilà pourquoi je milite pour que la licence de publication et distribution soit explicitement définie dans le RSS ou l'Atom: en l'état actuel, ils peuvent très bien dire que le fil est disponible mais qu'il n'est pas fait pour être utilisé (ben voyons). Avec une licence explicite incluse dans le flux, les choses seraient claires: soit on peut, soit on peut pas, il n'y aurait pas cet espèce de flou qui permet aux non-informaticiens (ceux qui pensent qu'ils maitrisent les nouvelles technologies parce qu'ils ont ouvert un skyblog) d'exploiter ce vide juridique.
Dans ce cas, tu aurais pu leur montrer le fil RSS dont ils sont responsable de publication et qui indique qu'ils autorise expressément la réutilisation du contenu. Et dans ce cas, soit ils changent leur RSS, soit ils arrêtent de chouiner.
J'aurais presque envie de dire que c'est notre faute, à nous les informaticiens: on aurait dû prévoir le coup et mettre en place ce $*$£$ de champs dès le début.
Si j'avais voulu faire de la pub, j'aurais fait carrément une dépêche, je me serais pas géné :-) D'ailleurs mon lien n'est pas sur le site, mais sur le projet du site...
Ha mais tiens, je serais pas en train d'essayer de me justifier là ?? Mince, je me suis fait avoir !!! :-)
Ha mais je suis bien d'accord avec ça, sauf que vis à vis de la loi, ça devient mon problème: même si le fil RSS est VOLONTAIREMENT publié par le webmaster, son contenu reste sujet au droit d'auteur.
Autrement dit, selon la loi française, rien n'empêche quelqu'un de publier un fil RSS et ensuite de faire un procès pour contrefaçon aux sites qui les utilisent et les publient.
Ouliblog n'est pas attaquable sur ce plan là. Au début, on pouvait se ballader sur les comptes ouliblog des utilisateurs et voir directement les billets de leurs fils RSS, ce qui était pratique et rapide pour se faire une idée du blog.
Suite à ce retour d'expérience j'ai fini par n'autoriser la lecture des billets qu'aux utilisateurs dûment loggés. Aux yeux de la loi, l'affichage n'est donc plus public, mais privé (il n'est pas disponible publiquement aux visiteurs, il n'est visible que pour les utilisateurs enregistrés). De cette façon, ouliblog n'est pas attaquable pour contrefaçon.
Ce n'est pas si grave, mais ça reste dommage : si les webmasters qui publient leur RSS le faisaient correctement, tout le monde en sortirait gagnant.
Par contre, j'ai l'exemple d'au moins une plateforme française de blogging qui "bloque" mon robot (il me renvoie un "banned" quand j'essaie de récupérer le rss). Ce n'est pas très grave, mais ça me laisse tout de même très perplexe, pour les raisons que j'ai évoquées dans le journal : il est si facile de choisir ce qu'on publie, que croire qu'un aggrégateur de rss est un concurrent possible qui "vole" du contenu, hé bien ça me laisse songeur....
Si c'est vraiment urgent, y a qu'une méthode vraiment efficace: les ciseaux et la colle. Si t'as le coup de main, tu peux te faire 3 pages à la minutes... facile.
Sinon, le truc le plus jouable (mais à mon avis c'est pas gagné non plus), c'est de convertir ton document word en RTF, puis d'essayer une moulinette RTF -> Latex.
Il y en a par exemple là: http://www.ctan.org/tex-archive/support/
C'est juste une piste, il y en a peut-être d'autres, j'ai jamais essayé, et j'espère ne jamais avoir à le faire.
Bonne chance, n'oublie pas de revenir nous faire part de ton expérience.
le .netrc est utilisé par tout un tas d'application, de emacs à wget, pour pouvoir te connecter à une machine sans avoir à fournir le mot de passe à chaque fois.
Je n'ai jamais utilisé cadaver, mais il y a de bonne chances pour qu'il prenne en compte ton .netrc (s'il a été compilé pour l'utiliser, sinon il faut le faire), et il se connectera sans te demander de mot de passe. C'est justement le comportement qu'il te faut pour un script...
Tout simplement, ils jouent une stratégie de coopération avec le concurrent de leur navigateur, afin de pouvoir exhiber les preuves de cette coopération et de cette volonté de leur part de ne pas phagocyter les autres produits et de ne pas cacher leurs protocoles.
Ainsi, le nom officiel “Windows Internet Explorer 7 in Windows Vista” est sensé bien montrer que IE7 fait partie intégrante de Windows Vista (par opposition à ce qui était fait avant, la preuve c'est qu'il faut dire en revanche “Windows Internet Explorer 7 for Windows XP”).
Tout cela est très fin, ils se créent simplement des arguments leur permettant de parer par la suite aux attaques de l'une des grosses administrations mondiales (américaine ou européenne). De toute façon cela ne mange pas de pain, car les API de Vista seront de toute façon publiées (via le réseau MSDN), d'autant que FF est une application comme les autres, qui n'a pas besoin d'informations spéciales sur le système d'exploitation.
La présentation des API va peut-être faire gagner un peu de temps, mais les développeurs auraient de toute façon fini par les utiliser (ou pas), et ça ne change pas grand chose. Le but, AMHA, c'est vraiment de montrer des efforts de coopération avec des produits concurrents.
Quand on se voit infliger des amendes pour près de 800M d'euros par la commission européenne parce qu'on a pas donné d'information sur ses protocoles et ses formats de données, je vous assure qu'on a tendance à préparer un peu ses arrières pour éviter que ça se reproduise...
"man rcp" ou "man scp" (pour la version ssh, sécurisée).
Sinon un ftp scripté peut aussi faire l'affaire, par exemple "ncftpget" (qui peut copier récursivement un répertoire).
Vu le nombre exponentiel de sites qui utilisent de l'ajax et autres fioritures qui, il faut bien le reconnaitre, apportent malgré tout un vrai plus à la navigation, je trouve que le rapport entre le risque réel et le désagrément causé par l'attention à porter à l'activation/désactivation manuelle du javascript ne vaut pas le coup (AMHA).
Concrètement, Javascript a des règles de sécurités assez strictes, qui d'une part empêchent les applications d'avoir accès aux données des autres fenêtres (ou onglets), et d'autre part les empêchent d'accéder aux resources de la machine.
En revanche, on peut imaginer sans problème une application javascript qui va tenter de parcourir ton réseaux pour obtenir des informations sur la topologie de ton réseaux interne et éventuellement sur tes applications web qui tourneraient dessus, mais si tu n'as rien de particulierement sensible qui tourne ou si tu n'as que ta machine, ça n'a rien de tracassant... Mais c'est toujours AMHA, car chacun a sa sensibilité propre sur ce qu'il considère dangereux pour sa vie privé.
Sinon, pour FF il y a un truc très bien, c'est la Web Developer toolbar (https://addons.mozilla.org/firefox/60/ ) parce qu'elle a non seulement un bouton disable qui permet de désactiver rapidement java et javascript (mais aussi le cache, le referrer, et les redirects), mais a aussi plein de trucs très intéressants, comme l'affichage de tout le code javascript tournant sur une page, l'affichage des headers renvoyés par le serveur, et surtout (le truc indispensable pour moi), un fonctionnalité View-Source qui ne t'affiche pas simplement la page telle que renvoyée par le serveur (ce que fait le view-source de base de FF), mais te donne la source APRES que le javascript soit passé par là et ait modifié le HTML de la page.... autrement dit, elle t'affiche le source final de la page telle que tu la vois.
Je pige pas trop... Si tu as les limites des départements, étant donné qu'une région est composée de départements, je serais tenté de dire qu'il est trivial de calculer les limites des régions...
Ca n'est pas prêt d'arriver, parce que les opérateurs sont totalement paranoiaques et imposent aux constructeurs de mobile des exigences innnombrables sur la sécurité des appareils... Ca n'est pas un hasard si c'est Java qui s'est imposé comme moteur d'exécution, malgré sa lenteur, parce qu'il permet un contrôle très pointu de la sécurité (un programme java s'exécutant dans un environnement contrôlé).
Leur hantise, c'est que les informations permettant de se connecter à leur réseau et d'utiliser leur infrastructure tombent dans des mains peu recommandables... C'est pour ça qu'autant un moteur d'exécution open-source sur un téléphone du commerce, aucun problème (d'ailleurs J2ME devrait prochainement l'être), mais un firmware totalement libre, j'ai dû mal à croire qu'un opérateur puisse accepter ça sur son réseau...
Ha ok, je ne connaissais pas cette variante syntaxique.
Pour répondre à ta question, il faut que tu te figures comment fonctionne un automate: en gros un ensembre d'états reliés entre eux par des chemins (les "transitions").
H[^o]*o est avantageux parce qu'il se résume au graphe suivant:
[H] -> [tout sauf o] -> [o] -> FIN
\-> [o] -> FIN
H.*o lui, se fait ainsi:
[H] -> [tout, y compris o] -> o -> FIN
\-> [o] -> FIN
Autrement dit, dans le premier cas, on a un automate déterministe (DFA), et dans le second cas on a un automate non-déterministe (NFA). La différence entre les deux, c'est que dans le cas du DFA, quand on est dans un état donné, il n'y a jamais deux transitions possible pour un même symbole en entrée (disons une lettre dans notre cas). Ca peut sembler pas grand chose, mais au niveau de l'implémentation et de la complexité, ça n'a rien à voir.
En effet, le parcours d'un automate DFA est par nature beaucoup plus rapide qu'un automate NFA parce que le premier peut s'effectuer en une seule passe et sans backtrack, alors que dans le second cas il faut soit le convertir en DFA (mais ça peut engendrer des DFA monstrueux, et ce n'est pas toujours envisageable), soit avoir un moteur NFA (qui backtracke ou qui parcourt en parallèle si on est riche en RAM), qui sont toujours (beaucoup) plus complexe et plus lent qu'un moteur DFA.
Evidemment, dans le cas de H.*o, si la chaine en entrée est pas trop grande, tu ne verras pas la différence en terme de traitement derrière, mais il n'empêche que le traitement que cela implique est "par nature" plus important.
Je ne sais pas ce que tu appelles "opérateur possessif", mais je vais quand même essayer de répondre (parce que je sais écrire un moteur de regexp :-)).
C'est assez simple en fait, une moteur d'expression régulière est un automate déterministe qui va simplement s'appliquer à parcourir un automate. La seule difficulté d'un tel automate est de résoudre les ambiguïtés qui l'obligent soit à "backtracker", c'est-à-dire à revenir en arrière sur l'automate, soit à gérer les différents parcours possibles en parallèle.
Lorsqu'il existe des ambiguités, d'une part le moteur est forcé de choisir entre :
- prendre le matching le plus court dans la chaine à parcourir
- prendre le matching le plus long dans la chaine à parcourir
Comme il n'existe pas toujours de syntaxe permettant de le préciser (souvent c'est un paramètre optionnel donné au moteur), il existe toujours une possibilité pour que ça ne corresponde pas à ce que veut l'utilisateur.
Reprenons le cas que tu donnes. D'abord, tes deux expressions ne sont pas équivalentes. Soit, par exemple "Hooaioo".
Les matchs partiels possibles sont:
"Hoo" (H.*?o et H[^o]*o)
"Hooaio" (H.*?o uniquement)
"Hooaioo" (H.*?o uniquement)
Maintenant, compliquons un peu l'exemple, testons-le avec l'expression (H.*o.*o). Il existe alors plusieurs matchs possibles:
- H + [vide] + o + oaio + o
- H + o + o + aio + o
- H + ooai + o + [vide] + o
- etc
La question pour le moteur est alors: laquelle choisir ? Soit le moteur est simple, et il prend la première qu'il trouve (en fonction de son implémentation), soit il est plus compliqué et va choisir celle qui favorise le match le plus long ou le plus court (dans le cas du matching partiel de l'exemple d'avant).
Dans ton exemple, je ne dirais pas que l'une des expression est meilleure que l'autre en soi, mais plutôt qu'elles ne matchent pas les mêmes chaines, l'une étant plus puissante (au sens puissance génératrice) donc plus complexe à parcourir. Mais ça n'est un problème que si le temps d'exécution est critique.
Autrement, le problème classique est d'utiliser une expression qui ne soit pas plus puissante que ce que tu veux parser (car ça peut laisser passer des choses non-valides, ce qui peut --ou pas-- être un problème), mais qui le soit suffisamment pour ne pas rejeter une chaine valide (car là c'est toujours un problème).
En règle générale, si tu évites les ambiguités de parcours, c'est toujours plus rapide. Typiquement, une expression telle que "aa*b" va systématiquement obliger le moteur à faire un choix, ce qui n'est jamais bon, il vaut toujours mieux mettre "a+b" qui n'est pas ambigu.
Pour ta question subsidiaire, la réponse est OUI et NON :-)
- d'abords, avec deux opérateurs possiblement vides à la suite (.* et ?) c'est sûr que tu facilites pas le travail du moteur, donc plutôt préférer tout simplement "<p.*>"
- ensuite OUI, car "<p[^>]*>" sera toujours moins ambigu que "<p.*?>", ce qui est BIEN, d'autant que "<p.*?>" peut aussi matcher la chaine "<p>toto<p>" (avec .* = ">toto<p")
- mais peut-être que NON, car "<p[^>]*>" ne matchera pas comme tu le souhaites une chaine (non valide xhtml, je le reconnais, mais qui passe en html) telle que "<p align='>'>".
Donc ça dépend ce que tu veux parser. Un autre problème majeur des expressions régulières, comme tu le vois, c'est qu'on en arrive vite au bout, et qu''il faut ensuite passer aux vraies grammaires, qui sont plus compliquées à mettre en oeuvre.
Je viens de faire le test, mais sans X parce que je n'ai qu'un serveur sans écran...
J'ai fait un petit script shell appelé /usr/local/bin/montest.sh
avec un "chmod a+rx /usr/local/bin/montest.sh"
Le script contient:
#!/bin/bash
echo "Quelle est la couleur du cheval blanc d'Henri IV ?"
read reponse
reponse=`echo $reponse|tr "a-z" "A-Z"`
if [[ "$reponse" == "BLANC" ]]
then
echo BRAVO !!
/bin/bash
else
echo "MAUVAISE REPONSE"
exit
fi
[^] # Re: effectivement...
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 2.
Il y a à la fois une interprétation stricte qui est qu'on ne récupère pas une oeuvre soumise au droit d'auteur sans l'accord du propriétaire des droits patrimoniaux... Et il y a une autre interprétation,que j'ai évoquée et à laquelle je me raccrochais (et à laquelle j'aurais aimé pouvoir me raccrocher davantage) qui est que quand on publie un fil RSS, c'est qu'on autorise son exploitation (un peu comme si on publiait un site web et qu'en même temps on ne voulait pas que les gens y viennent).
Tant que cela n'aura pas été jugé, on peut très bien ergoter pour l'une ou pour l'autre. D'autre part, je ne suis pas idiot, même si je préfère largement la seconde interprétation, parce qu'elle correspond à ma sensibilité, je pense qu'un tribunal aura tendance à favoriser la première, plus stricte. Malheureusement.
Comme je l'ai dit, le seul moyen pour régler le problème, c'est que le droit d'exploitation soit clairement précisé dans le fil RSS.
[^] # Re: effectivement...
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 0.
Je te remercie pour tes considérations sur le droit d'auteurs, même si tu ne m'apprends plus grand chose, mais à aucun moment je n'ai dit qu'il fallait le baffouer.
Si tu quittais un instant ton habit de super-héros qui défend aveuglement le droit d'auteur, si tu fréquentais un peu les blogs, bref, si tu connaissais un peu le sujet, tu saurais qu'il y a une majorité de bloggeurs qui sont tout à fait satisfait des aggrégateurs en ligne, qui contribuent à leur offrir une meilleure visibilité. Il y a évidemment toujours les autres, qui considèrent cela comme une violation de leur droit d'auteur, et c'est leur droit, et il faut les respecter. Cela, c'est acquis.
Mon propos, c'est qu'il faut justement permettre à chacun des bloggeurs d'établir leurs conditions d'utilisation pour leurs fils RSS, de manière à ce qu'il soit possible de récupérer et de republier les fils RSS de ceux qui l'autorisent (je répète: DE CEUX QUI L'AUTORISENT).
> C'est au contraire quelques informaticiens qui croient pouvoir changer la protection légale ou passer outre jusqu'à qu'on les rappelle explicitement à l'ordre.
Comme c'est charmant. Un complexe de supériorité de ta part sans doute, maintenant que tu as lu en diagonale le code de la propriété intellectuelle ?
Tu es tellement persuadé que tout le monde baffoue le droit d'auteur que tu n'imagines même pas un seul instant que certains bloggeurs VEULENT autoriser la publication de leur contenu, et que ton comportement sclérosé ne contribue qu'à les en empêcher. Merci, on a bien compris qu'on n'avait pas le droit, maintenant ce qu'on voudrait c'est pouvoir avancer un peu dans la bonne direction.
[^] # Re: Du DRM dans les RSS ?
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 3.
Les deux récupèrent, stockent, et affichent à leur manière des articles publiés. De la même manière, ces billets ne sont accessibles qu'à leur utilisateur.
Si ton aggrégateur de bureau stockait ses données sur une base de données sur le web, ce serait bien pareil. S'il affichait ses données via une interface web, ça serait tout pareil également. S'il affiche ses données via une interface web avec une base de données distante sur le web, ça reste pareil.
Si tu lis ton lecteur RSS de bureau est un programme Gnome ou KDE (disons basé sur X-Window) qui s'affiche sur ton poste de travail mais qui tourne sur une machine distante quelque part sur le web, est-ce que tu vas considérer que la machine distante fait une publication ? Je suis sûr que non.
Je le répète, il ne s'agit pas d'une publication, il s'agit d'un logiciel privé de lecteur de RSS qui est opéré par un tiers et qui fonctionne sur une interface web.
[^] # Re: oui mais non
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 2.
Outre que le ton que tu emploies est inutilement aggressif et accusateur ("Encore faut'il le vouloir, le veux tu ?" -> inutile de sortir l'arsenal de l'inquisition, je suis justement ici pour poser le problème sur la table, pas pour recevoir une leçon de morale alors que précisément je suis d'accord à 100% sur le nécessaire respect des droits d'auteurs).
D'abord, comme je l'ai dit plus haut, le lien vers la sélection affiche PAR ERREUR les billets sélectionné par l'utilisateur. C'est une rémanence de l'ancien système d'affichage, qui est d'ailleurs corrigé à l'heure où je te parle. C'était le seul point problématique, et tu t'y engoufres comme si tout le site était destiné à la violation du droit d'auteur.
De plus, je maintiens : aucun billet (modulo le bug mentionné, qui est maintenant corrigé) n'est
- ni indexé à mon profit par les moteurs de recherches (les moteurs ne s'enregistrent pas comme utilisateur et n'ont donc pas accès aux billets)
- ni attribué à ouliblog, de quelque manière que ce soit (l'auteur et le site sont systématiquement mentionnés)
- Les fils RSS ne sont PAS visible au public, et il s'agit pas d'une publication,.
Je suis d'autant plus surpris par ta réaction que j'ai déjà discuté des problèmes de droits d'auteurs avec un avocat très remonté contre ouliblog, et qu'après avoir rajouté la restriction d'accès, il a reconnu sans problème qu'il n'y avait plus là de problème légal.
J'ai l'impression que tu me cites une liste exhaustive de griefs accumulés contre je-ne-sais-qui, et que tu cherches à me l'appliquer coûte que coûte, alors que je t'assure qu'à aucun moment je n'ai cherché à transigé sur le droit d'auteur.
Pour conclure:
> Légalement tu es en tort sans aucun doute possible. Tu copies, publies et présente un contenu. Tu casses trois des monopoles accordés à l'auteur quand il créé quelque chose. Pire faisant une extraction systématique et automatique de tout ce qui sort du flux RSS, tu tombes aussi très probablement sur le droit spécifique aux bases de données.
Là tu débloques. Le RSS est précisément fait pour une extraction systématique et automatique. Tu crois que c'est un format destiné à être affiché, comme le HTML ? Absolument pas. Non, le RSS est fait pour les outils d'extraction, c'est son unique but. D'ailleurs, son premier objectif était de pouvoir afficher sur son site le contenu d'un autre site. Je ne sais pas pourquoi tu tiens absolument à m'accuser à tort et à travers, mais c'est très peu pertinent.
Pour être clair, il faut que tu comprennes bien que les billets dans ouliblog ne sont présentés qu'à ses utilisateurs privés, il ne s'agit pas d'une mise à disposition du public, et il ne s'agit pas d'une publication.
Pour répondre au "pire en faisant une extraction systématique et automatique de tout ce qui sort du flux"... je préfère te fournir un extrait du code de la propriété intellectuelle:
Art. L. 342-3. Lorsqu'une base de données est mise à la disposition du public par le titulaire des droits, celui-ci ne peut interdire :
1° L'extraction ou la réutilisation d'une partie non substantielle, appréciée de façon qualitative ou quantitative, du contenu de la base, par la personne qui y a licitement accès ;
2° L'extraction à des fins privées d'une partie qualitativement ou quantitativement substantielle du contenu d'une base de données non électronique sous réserve du respect des droits d'auteur ou des droits voisins sur les oeuvres ou éléments incorporés dans la base.
(Modification issue du projet de loi relatif au droit d’auteur et aux droits voisins dans la société de l’information voté par le Parlement le 30 juin 2006)
Le RSS rentre exactement dans ce cas là: il met à disposition une partie non-substantielle (souvent une vingtaine d'articles) de la base de données du blog.
Je pensais avoir tout vu, mais venir me dire que je pille une base de données parce que je vais récupérer un flux RSS qui est mis à disposition, je crois que ça bat tous les records. Je vais avoir du mal à m'en remettre :-)
[^] # Re: Du DRM dans les RSS ?
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 4.
>Légalement ça ne change rien.
Ho que si, ça change tout. Et si j'ai changé la politique d'affichage de ouliblog pour que les billets ne soit plus accessibles qu'aux utilisateurs, c'est parce que dans ce dernier cas il ne s'agit plus d'une publication strictu sensu, et que ça n'est pas proscrit par la loi.
D'ailleurs pour tout te dire, c'est suite à un échange très intéressant par mail avec un bloggeur juriste (avocat de profession) qui était très à cheval sur son droit d'auteur et qui se plaignait d'ouliblog que nous sommes arrivés à cette conclusion (bon, soyons honnêtes, c'est lui qui y est arrivé). Alors ça n'est pas écrit dans le marbre, mais pour avoir consulté quelques juristes, je suis assez sûr de moi pour dormir tranquille de ce côté là (modulo le bug que tu as repéré et que je vais rapidement corriger).
> C'est effectivement dommage, mais qui a dérappé ? l'auteur ou l'aggrégateur qui n'a pas respecté les désidérata ?
Le problème c'est que le RSS est un format destiné à la syndication, donc à la publication externe de contenu, et que l'utilisation en soi de ce format de publication est une indication de la volonté de l'auteur. On peut ne pas être d'accord avec ça, mais c'est défendable. Si je fabrique des stickers autocollant et que je les distribue, puis-je décemment me plaindre que les gens vont les coller ? Si mon désir en tant qu'auteur est que les gens ne les collent pas, hé bien il suffit de faire des stickers qui ne soit pas auto-collant. Elle a souvent bon dos, la volonté de l'auteur, mais je le répète, quelqu'un qui ne veut pas qu'on affiche son contenu ailleurs que chez lui peut TOUT SIMPLEMENT ne pas publier de fil RSS, auquel cas tout malentendu disparait.
Après, il faut être juste, quand les aggrégateurs ne respectent pas la volonté des auteurs, c'est en général parce que ces derniers n'ont pas de moyen technique pour l'exprimer. Et là, je pense qu'on est tous d'accord, il faudrait vraiment que ça soit, non seulement techniquement possible, mais pratiquement obligatoire dans la norme, d'exprimer les conditions d'utilisation du flux RSS.
[^] # Re: effectivement...
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 3.
Cela dit, publier un fil RSS, c'est quand même faire un acte volontaire de publication dans un format qui s'appelle "Really Simple Syndication", autrement dit dans un format fondamentalement fait pour la syndication. D'ailleurs les sites comme le monde ou libération l'ont très bien compris, puisqu'ils se contentent de ne mettre dans le RSS que ce qui est librement publiable ailleurs, les gens devant aller sur leur site pour lire le contenu.
Pour le champ "copyright", malheureusement non, il n'est pas utilisable. D'abord parce que tout contenu est soumis au droit d'auteur (et au copyright), mais ça n'empêche pas que le contenu soit librement diffusable et publiable. Il n'y a pas de corrélation possible entre ces deux notions, sinon que l'une dépend de l'autre (il faut que je possède le copyright/droit d'auteur pour avoir le droit de définir la licence de publication/distribution sur le contenu).
En tout cas, nous sommes d'accord, il faut que la volonté des auteurs soit respectée, mais il faut *aussi* qu'elle soit clairement apréhendable par les outils: il faut donc un licence systématique et explicite sur le contenu des fils RSS/Atom.
[^] # Re: effectivement...
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 2.
Voilà pourquoi je milite pour que la licence de publication et distribution soit explicitement définie dans le RSS ou l'Atom: en l'état actuel, ils peuvent très bien dire que le fil est disponible mais qu'il n'est pas fait pour être utilisé (ben voyons). Avec une licence explicite incluse dans le flux, les choses seraient claires: soit on peut, soit on peut pas, il n'y aurait pas cet espèce de flou qui permet aux non-informaticiens (ceux qui pensent qu'ils maitrisent les nouvelles technologies parce qu'ils ont ouvert un skyblog) d'exploiter ce vide juridique.
Dans ce cas, tu aurais pu leur montrer le fil RSS dont ils sont responsable de publication et qui indique qu'ils autorise expressément la réutilisation du contenu. Et dans ce cas, soit ils changent leur RSS, soit ils arrêtent de chouiner.
J'aurais presque envie de dire que c'est notre faute, à nous les informaticiens: on aurait dû prévoir le coup et mettre en place ce $*$£$ de champs dès le début.
[^] # Re: En tout cas....
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 6.
Ha mais tiens, je serais pas en train d'essayer de me justifier là ?? Mince, je me suis fait avoir !!! :-)
[^] # Re: Du DRM dans les RSS ?
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 2.
Autrement dit, selon la loi française, rien n'empêche quelqu'un de publier un fil RSS et ensuite de faire un procès pour contrefaçon aux sites qui les utilisent et les publient.
Ouliblog n'est pas attaquable sur ce plan là. Au début, on pouvait se ballader sur les comptes ouliblog des utilisateurs et voir directement les billets de leurs fils RSS, ce qui était pratique et rapide pour se faire une idée du blog.
Suite à ce retour d'expérience j'ai fini par n'autoriser la lecture des billets qu'aux utilisateurs dûment loggés. Aux yeux de la loi, l'affichage n'est donc plus public, mais privé (il n'est pas disponible publiquement aux visiteurs, il n'est visible que pour les utilisateurs enregistrés). De cette façon, ouliblog n'est pas attaquable pour contrefaçon.
Ce n'est pas si grave, mais ça reste dommage : si les webmasters qui publient leur RSS le faisaient correctement, tout le monde en sortirait gagnant.
Par contre, j'ai l'exemple d'au moins une plateforme française de blogging qui "bloque" mon robot (il me renvoie un "banned" quand j'essaie de récupérer le rss). Ce n'est pas très grave, mais ça me laisse tout de même très perplexe, pour les raisons que j'ai évoquées dans le journal : il est si facile de choisir ce qu'on publie, que croire qu'un aggrégateur de rss est un concurrent possible qui "vole" du contenu, hé bien ça me laisse songeur....
# A l'ancienne...
Posté par deadbeef . En réponse au message Latex : Insérer un document word dans un document latex. Évalué à 2.
Sinon, le truc le plus jouable (mais à mon avis c'est pas gagné non plus), c'est de convertir ton document word en RTF, puis d'essayer une moulinette RTF -> Latex.
Il y en a par exemple là:
http://www.ctan.org/tex-archive/support/
C'est juste une piste, il y en a peut-être d'autres, j'ai jamais essayé, et j'espère ne jamais avoir à le faire.
Bonne chance, n'oublie pas de revenir nous faire part de ton expérience.
[^] # Re: .netrc
Posté par deadbeef . En réponse au message script bash et webdav. Évalué à 2.
Je n'ai jamais utilisé cadaver, mais il y a de bonne chances pour qu'il prenne en compte ton .netrc (s'il a été compilé pour l'utiliser, sinon il faut le faire), et il se connectera sans te demander de mot de passe. C'est justement le comportement qu'il te faut pour un script...
# xml2-config
Posté par deadbeef . En réponse au message Compilation PHP avec XML. Évalué à 2.
Vérifie aussi que la commande se trouve bien dans ton package d'installation (par exemple avec rpm -ql libxml2-devel si c'était un packet rpm).
# .netrc
Posté par deadbeef . En réponse au message script bash et webdav. Évalué à 2.
Dans le fichier $HOME/.netrc, mettre :
# Ils anticipent la prochaine attaque "antitrust"...
Posté par deadbeef . En réponse au journal Microsoft veut coopérer avec l'équipe Mozilla pour le dev de firefox. Évalué à 9.
On retrouve déjà cette préparation stratégique dans la terminologie qu'ils mettent en avant:
http://blogs.msdn.com/ie/archive/2006/08/04/688899.aspx
Ainsi, le nom officiel “Windows Internet Explorer 7 in Windows Vista” est sensé bien montrer que IE7 fait partie intégrante de Windows Vista (par opposition à ce qui était fait avant, la preuve c'est qu'il faut dire en revanche “Windows Internet Explorer 7 for Windows XP”).
Tout cela est très fin, ils se créent simplement des arguments leur permettant de parer par la suite aux attaques de l'une des grosses administrations mondiales (américaine ou européenne). De toute façon cela ne mange pas de pain, car les API de Vista seront de toute façon publiées (via le réseau MSDN), d'autant que FF est une application comme les autres, qui n'a pas besoin d'informations spéciales sur le système d'exploitation.
La présentation des API va peut-être faire gagner un peu de temps, mais les développeurs auraient de toute façon fini par les utiliser (ou pas), et ça ne change pas grand chose. Le but, AMHA, c'est vraiment de montrer des efforts de coopération avec des produits concurrents.
Quand on se voit infliger des amendes pour près de 800M d'euros par la commission européenne parce qu'on a pas donné d'information sur ses protocoles et ses formats de données, je vous assure qu'on a tendance à préparer un peu ses arrières pour éviter que ça se reproduise...
# scp / rcp
Posté par deadbeef . En réponse au message commande sur la copie de fichier. Évalué à 3.
Sinon un ftp scripté peut aussi faire l'affaire, par exemple "ncftpget" (qui peut copier récursivement un répertoire).
# Pas Rano mais presque... :-)
Posté par deadbeef . En réponse au message Racourci Firefox. Évalué à 3.
Concrètement, Javascript a des règles de sécurités assez strictes, qui d'une part empêchent les applications d'avoir accès aux données des autres fenêtres (ou onglets), et d'autre part les empêchent d'accéder aux resources de la machine.
En revanche, on peut imaginer sans problème une application javascript qui va tenter de parcourir ton réseaux pour obtenir des informations sur la topologie de ton réseaux interne et éventuellement sur tes applications web qui tourneraient dessus, mais si tu n'as rien de particulierement sensible qui tourne ou si tu n'as que ta machine, ça n'a rien de tracassant... Mais c'est toujours AMHA, car chacun a sa sensibilité propre sur ce qu'il considère dangereux pour sa vie privé.
Sinon, pour FF il y a un truc très bien, c'est la Web Developer toolbar (https://addons.mozilla.org/firefox/60/ ) parce qu'elle a non seulement un bouton disable qui permet de désactiver rapidement java et javascript (mais aussi le cache, le referrer, et les redirects), mais a aussi plein de trucs très intéressants, comme l'affichage de tout le code javascript tournant sur une page, l'affichage des headers renvoyés par le serveur, et surtout (le truc indispensable pour moi), un fonctionnalité View-Source qui ne t'affiche pas simplement la page telle que renvoyée par le serveur (ce que fait le view-source de base de FF), mais te donne la source APRES que le javascript soit passé par là et ait modifié le HTML de la page.... autrement dit, elle t'affiche le source final de la page telle que tu la vois.
# df ?
Posté par deadbeef . En réponse au message espace disque. Évalué à 3.
"df /home" dans une console...
# hu?
Posté par deadbeef . En réponse au message coordonées des limites des régions françaises. Évalué à 3.
Quel est ta difficulté ?
[^] # Re: Je n'ai pas encore de téléphone portable
Posté par deadbeef . En réponse au journal un téléphone portable sous Linux ... ouvert ?. Évalué à 3.
Leur hantise, c'est que les informations permettant de se connecter à leur réseau et d'utiliser leur infrastructure tombent dans des mains peu recommandables... C'est pour ça qu'autant un moteur d'exécution open-source sur un téléphone du commerce, aucun problème (d'ailleurs J2ME devrait prochainement l'être), mais un firmware totalement libre, j'ai dû mal à croire qu'un opérateur puisse accepter ça sur son réseau...
# La seule chose intelligente à faire...
Posté par deadbeef . En réponse au message Symbiose Mail-Forum. Évalué à 2.
# find | xargs grep
Posté par deadbeef . En réponse au message Recherche d'une expression dans un fichier. Évalué à 1.
find . -type f | xargs grep -ni 'expression'
[^] # Re: je me lance...
Posté par deadbeef . En réponse au message Expressions régulières: votre avis.... Évalué à 3.
Pour répondre à ta question, il faut que tu te figures comment fonctionne un automate: en gros un ensembre d'états reliés entre eux par des chemins (les "transitions").
H[^o]*o est avantageux parce qu'il se résume au graphe suivant:
[H] -> [tout sauf o] -> [o] -> FIN
\-> [o] -> FIN
H.*o lui, se fait ainsi:
[H] -> [tout, y compris o] -> o -> FIN
\-> [o] -> FIN
Autrement dit, dans le premier cas, on a un automate déterministe (DFA), et dans le second cas on a un automate non-déterministe (NFA). La différence entre les deux, c'est que dans le cas du DFA, quand on est dans un état donné, il n'y a jamais deux transitions possible pour un même symbole en entrée (disons une lettre dans notre cas). Ca peut sembler pas grand chose, mais au niveau de l'implémentation et de la complexité, ça n'a rien à voir.
En effet, le parcours d'un automate DFA est par nature beaucoup plus rapide qu'un automate NFA parce que le premier peut s'effectuer en une seule passe et sans backtrack, alors que dans le second cas il faut soit le convertir en DFA (mais ça peut engendrer des DFA monstrueux, et ce n'est pas toujours envisageable), soit avoir un moteur NFA (qui backtracke ou qui parcourt en parallèle si on est riche en RAM), qui sont toujours (beaucoup) plus complexe et plus lent qu'un moteur DFA.
Evidemment, dans le cas de H.*o, si la chaine en entrée est pas trop grande, tu ne verras pas la différence en terme de traitement derrière, mais il n'empêche que le traitement que cela implique est "par nature" plus important.
Si tu veux les maths derrière tout ça:
http://en.wikipedia.org/wiki/Deterministic_finite_state_mach(...)
http://en.wikipedia.org/wiki/Nondeterministic_finite_state_m(...)
# spamassassin
Posté par deadbeef . En réponse au message Boite email plein. Évalué à 1.
# je me lance...
Posté par deadbeef . En réponse au message Expressions régulières: votre avis.... Évalué à 5.
C'est assez simple en fait, une moteur d'expression régulière est un automate déterministe qui va simplement s'appliquer à parcourir un automate. La seule difficulté d'un tel automate est de résoudre les ambiguïtés qui l'obligent soit à "backtracker", c'est-à-dire à revenir en arrière sur l'automate, soit à gérer les différents parcours possibles en parallèle.
Lorsqu'il existe des ambiguités, d'une part le moteur est forcé de choisir entre :
- prendre le matching le plus court dans la chaine à parcourir
- prendre le matching le plus long dans la chaine à parcourir
Comme il n'existe pas toujours de syntaxe permettant de le préciser (souvent c'est un paramètre optionnel donné au moteur), il existe toujours une possibilité pour que ça ne corresponde pas à ce que veut l'utilisateur.
Reprenons le cas que tu donnes. D'abord, tes deux expressions ne sont pas équivalentes. Soit, par exemple "Hooaioo".
Les matchs partiels possibles sont:
"Hoo" (H.*?o et H[^o]*o)
"Hooaio" (H.*?o uniquement)
"Hooaioo" (H.*?o uniquement)
Maintenant, compliquons un peu l'exemple, testons-le avec l'expression (H.*o.*o). Il existe alors plusieurs matchs possibles:
- H + [vide] + o + oaio + o
- H + o + o + aio + o
- H + ooai + o + [vide] + o
- etc
La question pour le moteur est alors: laquelle choisir ? Soit le moteur est simple, et il prend la première qu'il trouve (en fonction de son implémentation), soit il est plus compliqué et va choisir celle qui favorise le match le plus long ou le plus court (dans le cas du matching partiel de l'exemple d'avant).
Dans ton exemple, je ne dirais pas que l'une des expression est meilleure que l'autre en soi, mais plutôt qu'elles ne matchent pas les mêmes chaines, l'une étant plus puissante (au sens puissance génératrice) donc plus complexe à parcourir. Mais ça n'est un problème que si le temps d'exécution est critique.
Autrement, le problème classique est d'utiliser une expression qui ne soit pas plus puissante que ce que tu veux parser (car ça peut laisser passer des choses non-valides, ce qui peut --ou pas-- être un problème), mais qui le soit suffisamment pour ne pas rejeter une chaine valide (car là c'est toujours un problème).
En règle générale, si tu évites les ambiguités de parcours, c'est toujours plus rapide. Typiquement, une expression telle que "aa*b" va systématiquement obliger le moteur à faire un choix, ce qui n'est jamais bon, il vaut toujours mieux mettre "a+b" qui n'est pas ambigu.
Pour ta question subsidiaire, la réponse est OUI et NON :-)
- d'abords, avec deux opérateurs possiblement vides à la suite (.* et ?) c'est sûr que tu facilites pas le travail du moteur, donc plutôt préférer tout simplement "<p.*>"
- ensuite OUI, car "<p[^>]*>" sera toujours moins ambigu que "<p.*?>", ce qui est BIEN, d'autant que "<p.*?>" peut aussi matcher la chaine "<p>toto<p>" (avec .* = ">toto<p")
- mais peut-être que NON, car "<p[^>]*>" ne matchera pas comme tu le souhaites une chaine (non valide xhtml, je le reconnais, mais qui passe en html) telle que "<p align='>'>".
Donc ça dépend ce que tu veux parser. Un autre problème majeur des expressions régulières, comme tu le vois, c'est qu'on en arrive vite au bout, et qu''il faut ensuite passer aux vraies grammaires, qui sont plus compliquées à mettre en oeuvre.
[^] # Re: /etc/passwd
Posté par deadbeef . En réponse au message Fais tes devoirs avant !. Évalué à 1.
J'ai fait un petit script shell appelé /usr/local/bin/montest.sh
avec un "chmod a+rx /usr/local/bin/montest.sh"
Le script contient:
#!/bin/bash
echo "Quelle est la couleur du cheval blanc d'Henri IV ?"
read reponse
reponse=`echo $reponse|tr "a-z" "A-Z"`
if [[ "$reponse" == "BLANC" ]]
then
echo BRAVO !!
/bin/bash
else
echo "MAUVAISE REPONSE"
exit
fi
et j'ai modifié mon /etc/passwd comme ceci:
test:x:1006:1006:test,,,:/home/test:/usr/local/bin/montest.sh
(hint: avec bash 3.0, tu peux aussi faire comparaisons avec des expressions régulières, ça peut être utile pour un quizz)