ça fait 8 ans que je bosse, 8 ans que j'utilise vim. J'interviens sur du soft avec quelques centaines de milliers de lignes, est-ce que tu considères que c'est un gros truc ou c'est pas encore assez ? ;)
et qualifier vim de "bête" éditeur de texte ... si tous les softs qu'on utilise pouvait être aussi "bête", je serais content.
L'outil technique n'est qu'un élément de la gestion de conf. Ce que tu décris, ça me paraît plutôt être un problème de process. Utiliser un gestionnaire de conf centralisé est un moyen de pallier le problème que vous rencontrez, mais ça serait sûrement possible d'aboutir au même résultat avec d'autres outils.
Ce n'est pas le cas aujourd'hui, mais si j'avais du code à diffuser, ça serait via un gestionnaire de conf distribué sans hésitation.
Sans connaissance particulière de gestionnaire de conf, je serais aussi parti sur du distribué.
J'utilise cvs chez moi, mais vraiment pour une seule raison (je veux dire, en dehors du fait que ça marche) : c'est un outil que je connais déjà très bien.
du coup, si tu n'es pas plus à l'aise que ça avec svn, je te conseillerais plutôt de taper sur du distribué. Quant à savoir lequel .. heu ... joker ?
(pas d'expérience sur migration de svn vers autre chose non plus)
heu, c'est pas le contraire ?
de ce que je vois dans tes deux lignes, la première correspond le motif "said: blabla : d'autres trucs" tandis que la seconde est "said: blabla". Or la regex de mon commentaire s'appuyait sur la présence d'une seconde occurence du caractère ":".
C'est ce que je signalais dans mon commentaire précédent, il faut regarder tous les formats possibles après le said pour établir une regex qui matchera à tous les coups.
En partant des résultats de ce grep, tu pourras essayer d'établir une regex qui découpe ce motif à ta convenance, et la ré injecter dans le sed initial.
cat + 2 grep et un sed, ça fait beaucoup pour un truc qui peur se faire avec un seul sed :)
Un de tes problèmes ici est que ton grep -o restreint ta ligne à ce qui correspond à ton motif, et ton motif actuel exclut ce qui se trouve après > (donc ce qu'il y a après le said)
sed -ne 's/.*to=<\([^>]*\)>.*status=bounced.*said:[^:]*:/\1/p' /var/log/mail.log
concernant le motif commençant à "said", je m'appuie sur ton exemple car je ne connais pas le format général d'une ligne de bounced. Il faut potentiellement généraliser pour traiter les lignes qui ne serait pas du genre "said: du blablabla : le texte que tu veux"
Tu as visiblement un problème avec GMail ou Google qui se trouve au niveau de l'affect et non de la raison
Je dirais plutôt une saine application du principe de précaution. La meilleure garantie que Google continuera à se comporter "éthiquement" (j'utilise ce mot à défaut de mieux) est de ne pas leur donner les "moyens" (idem) de ne plus le faire.
je ne suis pas sûr que ça répondra, mais pour le dns 323 (dont je suis aussi un heureux propriétaire), une très bonne ressource : http://wiki.dns323.info/
et aussi une debian dispo là : http://www.ohloh.net/p/debnas
Après, si postfix n'est pas dispo, il peut se recompiler, vu que gcc, lui, l'est.
Du coup, pour un dns 323, c'est possible de faire des compils directement sur l'architecture cible, de récupérer d'un repository ou de cross compiler (mais curieusement, ça arrive moins souvent ;)
avec cette option (que je ne connaissais pas, comme quoi un commentaire pas très constructif (je parle du mien hein) peut déboucher sur quelque chose ;), ça fait 13 packages de moins. Il n'en reste plus que ... 43. Encore un petit trop pour moi.
$ sudo apt-get install ark
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
ghostscript gs-common gstreamer0.10-alsa gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-x htdig kaboom kde-icons-oxygen kdebase-runtime kdebase-runtime-bin-kde4 kdebase-runtime-data kdebase-runtime-data-common kdelibs-bin kdelibs5 kdelibs5-data khelpcenter4 libarchive1 libclucene0ldbl libdjvulibre-text libdjvulibre21 libdv4 libgraphviz4 libgs8 libilmbase6 liblqr-1-0 libmagickcore2 libmagickwand2 libopenexr6 libphonon4 libqt4-opengl libqt4-svg libsoprano4 libstreamanalyzer0 libstreams0 libvisual-0.4-0 libvisual-0.4-plugins libxcb-shape0 libxcb-shm0 libxcb-xv0 libxine1 libxine1-bin libxine1-console libxine1-ffmpeg libxine1-misc-plugins libxine1-plugins libxine1-x libxml2-utils libzip1 oxygen-icon-theme p7zip-full phonon-backend-gstreamer pmount psfontmgr soprano-daemon
mais non merci :)
Sinon, je vois dans les commentaires des trucs comme s'embêter à réfléchir(mention spéciale du jury), je n'ai pas à réfléchir ou plus besoin de réfléchir, je suis un peu horrifié. En l'occurrence, le mot réfléchir serait avantageusement remplacer par "se souvenir", "apprendre", "se rappeler", "penser à", ...
Ca va tant que tu n'as pas trop de données, parce que faire des concaténation et des like sur des chaînes de caractères en full scan, en terme de perfs, y a du potentiel de pas glop ...
C'est possible d'élaborer en rajoutant le nom de la table dans le prototype de la table précédente.
J'ai déjà vu une application résoudre ce genre de problème de cette façon, en rajoutant des tables dédiées à la recherche. Le hic, c'est qu'il faut du coup alimenter ces tables à la volée et que ça rajoute pas mal de complexité au code.
L'avantage, c'est que ça scale mieux que devoir faire une recherche multi champs multi table dans une seule grosse requête SQL monstrueuse. Tu peux aussi découper plus finement ta recherche en indexant mot par mot dans ces tables dédiées, plutôt qu'en indexant la totalité du contenu des champs.
sur le principe, c'est quand même un peu malsain de pas savoir ce que tu es en train de chercher.
Tu peux aussi avoir une table (valeur, type, id) triée sur valeur, ou type ferait référence au type de champ, et id pointerait sur l'id de la ligne contenant ta valeur. (c'est des noms moisis, c'est juste un exemple vite torché).
Tu chercherais valeur dans cette table et le résultat de cette recherche te permettrait immédiatement d'identifier quel(s) champ(s) de quelle(s) ligne(s) contient ta valeur.
Venant d'un expert comme toi qui lance des DDOS sur les réseaux sociaux juste pour soutenir ton argumentation (http://linuxfr.org/~farvardin/28636.html ), ton commentaire prend toute sa dimension ;-)
pour comprendre, il faut revenir aux raisons pour lesquelles SCO a porté plainte. En gros, si j'avais bien suivi à l'époque, IBM avait acheté à SCO le droit de voir les sources de l'Unix d'ATT mais avec un NDA assez sévère. Des gens d'IBM ont contribué à Linux.
SCO affirme que les employés d'IBM qui ont contribué à Linux sont les même que ceux qui avaient accès au code d'Unix, et que donc le noyau Linux est un derivative work d'Unix.
Rien de tel pour les *BSD (qui sont bien des unix, mais pas dans le périmètre de la plainte de SCO)
Ne rentrons pas dans le détail de la qualité de l'argument, tout a été soigneusement démonté à l'époque. Relisez groklaw comme suggéré dans un autre commentaire. Il serait temps de laisser ce troll mourir ;)
Réécrire des bouts du noyau (ou autre), c'est déjà galère
certes. Et ? C'est impossible ?
ou alors j'ai loupé quelque chose cette été !!!
ouais, mais c'était pas cet été. Depuis quelques temps déjà, Debian expérimente l'intégration d'autres noyaux que Linux. Y a eu une Debian/Hurd, des Debian/BSD.
Il me semble que c'est d'ailleurs pour ça que les packages du noyau (autrefois kernel-2.6*) ont été renommé en linux-image-2.6*.
sinon, je l'ai peut-être mal dit dans mon commentaire, mais pour moi, le vraiment pire qui pourrait arriver serait de devoir ré écrire des bouts de noyau. Maintenant, la probabilité qu'on en arrive jusque là est vraiment très faible, et vraiment pas à court/moyen terme.
Dans l'absolu, je prétend aussi que la fin du noyau Linux ne signe pas la fin du logiciel libre, et ça, ça me parait difficilement contestable.
Pour finir, c'est une histoire qui va se régler entre SCO, Novell, IBM, Redhat, ... Ca prendra du temps parce que les machins légaux entre grosses boites prennent toujours du temps, mais je serais vraiment surpris que ça sorte un jour de ce périmètre.
C'est simplement le titre du journal que je remet en cause.
Le pire qui pourrait arriver, c'est que les développeurs du noyau Linux soient obligés de réécrire des bouts du noyau. C'est tout.
Soyons ultra pessimistes, y a plus le droit d'utiliser Linux du tout, ça sera l'occasion de se pencher sérieusement sur debian/bsd !
bref, déjà que je ne me faisais pas trop de soucis pour Linux, je m'en fais encore moins pour le "Libre".
[^] # Re: Emacs ou vim?
Posté par gaaaaaAab . En réponse au message J'ai besion d'un IDE et j'en trouve pas °o°. Évalué à 10.
et qualifier vim de "bête" éditeur de texte ... si tous les softs qu'on utilise pouvait être aussi "bête", je serais content.
[^] # Re: Emacs ou vim?
Posté par gaaaaaAab . En réponse au message J'ai besion d'un IDE et j'en trouve pas °o°. Évalué à 3.
l'omni complétion est encore expérimentale (:help omni) mais ça viendra un jour =)
[^] # Re: Rien d'autre à faire ?
Posté par gaaaaaAab . En réponse au journal IPOT (IP over Time), c'est possible, avec une preuve !. Évalué à 2.
http://www.pcinpact.com/actu/news/26930-Concert-de-critiques(...)
[^] # Re: plutôt distribué
Posté par gaaaaaAab . En réponse au message A la recherche du meilleur outil .... Évalué à 2.
# plutôt distribué
Posté par gaaaaaAab . En réponse au message A la recherche du meilleur outil .... Évalué à 2.
Sans connaissance particulière de gestionnaire de conf, je serais aussi parti sur du distribué.
J'utilise cvs chez moi, mais vraiment pour une seule raison (je veux dire, en dehors du fait que ça marche) : c'est un outil que je connais déjà très bien.
du coup, si tu n'es pas plus à l'aise que ça avec svn, je te conseillerais plutôt de taper sur du distribué. Quant à savoir lequel .. heu ... joker ?
(pas d'expérience sur migration de svn vers autre chose non plus)
[^] # Re: Ca veut dire quoi bronsonisé ?
Posté par gaaaaaAab . En réponse au journal Filip Nikolic bronsonisé .... Évalué à 2.
ou alors plusieurs fois
# heu ?
Posté par gaaaaaAab . En réponse au message recupere les paramettres d"un programme associé à un alias. Évalué à 3.
exec /usr/informix/bin/dbaccess $*ou pas ?
pas sûr d'avoir compris la question non plus, mais exec $0, c'est de toute façon pas très très utile :).
[^] # Re: sed, c'est dien
Posté par gaaaaaAab . En réponse au message Afficher deux champs depuis un log. Évalué à 3.
de ce que je vois dans tes deux lignes, la première correspond le motif "said: blabla : d'autres trucs" tandis que la seconde est "said: blabla". Or la regex de mon commentaire s'appuyait sur la présence d'une seconde occurence du caractère ":".
C'est ce que je signalais dans mon commentaire précédent, il faut regarder tous les formats possibles après le said pour établir une regex qui matchera à tous les coups.
Fais un:
grep "status=bounced" /var/log/mail.log |grep -o "said.*"
En partant des résultats de ce grep, tu pourras essayer d'établir une regex qui découpe ce motif à ta convenance, et la ré injecter dans le sed initial.
# sed, c'est dien
Posté par gaaaaaAab . En réponse au message Afficher deux champs depuis un log. Évalué à 3.
Un de tes problèmes ici est que ton grep -o restreint ta ligne à ce qui correspond à ton motif, et ton motif actuel exclut ce qui se trouve après > (donc ce qu'il y a après le said)
sed -ne 's/.*to=<\([^>]*\)>.*status=bounced.*said:[^:]*:/\1/p' /var/log/mail.log
concernant le motif commençant à "said", je m'appuie sur ton exemple car je ne connais pas le format général d'une ligne de bounced. Il faut potentiellement généraliser pour traiter les lignes qui ne serait pas du genre "said: du blablabla : le texte que tu veux"
[^] # Re: ma surprise
Posté par gaaaaaAab . En réponse au journal Caramail revit, mais était-il mort ?. Évalué à -3.
Je dirais plutôt une saine application du principe de précaution. La meilleure garantie que Google continuera à se comporter "éthiquement" (j'utilise ce mot à défaut de mieux) est de ne pas leur donner les "moyens" (idem) de ne plus le faire.
[^] # Re: HS : installé comment ?
Posté par gaaaaaAab . En réponse au message Postfix sur NAS DNS-323. Évalué à 2.
et aussi une debian dispo là : http://www.ohloh.net/p/debnas
Après, si postfix n'est pas dispo, il peut se recompiler, vu que gcc, lui, l'est.
Du coup, pour un dns 323, c'est possible de faire des compils directement sur l'architecture cible, de récupérer d'un repository ou de cross compiler (mais curieusement, ça arrive moins souvent ;)
[^] # Re: merci
Posté par gaaaaaAab . En réponse au message Ark en ligne de commande. Évalué à 3.
# merci
Posté par gaaaaaAab . En réponse au message Ark en ligne de commande. Évalué à 5.
$ sudo apt-get install arkReading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
ghostscript gs-common gstreamer0.10-alsa gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-x htdig kaboom kde-icons-oxygen kdebase-runtime kdebase-runtime-bin-kde4 kdebase-runtime-data kdebase-runtime-data-common kdelibs-bin kdelibs5 kdelibs5-data khelpcenter4 libarchive1 libclucene0ldbl libdjvulibre-text libdjvulibre21 libdv4 libgraphviz4 libgs8 libilmbase6 liblqr-1-0 libmagickcore2 libmagickwand2 libopenexr6 libphonon4 libqt4-opengl libqt4-svg libsoprano4 libstreamanalyzer0 libstreams0 libvisual-0.4-0 libvisual-0.4-plugins libxcb-shape0 libxcb-shm0 libxcb-xv0 libxine1 libxine1-bin libxine1-console libxine1-ffmpeg libxine1-misc-plugins libxine1-plugins libxine1-x libxml2-utils libzip1 oxygen-icon-theme p7zip-full phonon-backend-gstreamer pmount psfontmgr soprano-daemon
mais non merci :)
Sinon, je vois dans les commentaires des trucs comme s'embêter à réfléchir(mention spéciale du jury), je n'ai pas à réfléchir ou plus besoin de réfléchir, je suis un peu horrifié. En l'occurrence, le mot réfléchir serait avantageusement remplacer par "se souvenir", "apprendre", "se rappeler", "penser à", ...
[^] # Re: Erreur de conception ?
Posté par gaaaaaAab . En réponse au message SELECT * FROM matable WHERE n'importeQuelChamp = 'maValeur'. Évalué à 6.
[^] # Re: Erreur de conception ?
Posté par gaaaaaAab . En réponse au message SELECT * FROM matable WHERE n'importeQuelChamp = 'maValeur'. Évalué à 4.
C'est possible d'élaborer en rajoutant le nom de la table dans le prototype de la table précédente.
J'ai déjà vu une application résoudre ce genre de problème de cette façon, en rajoutant des tables dédiées à la recherche. Le hic, c'est qu'il faut du coup alimenter ces tables à la volée et que ça rajoute pas mal de complexité au code.
L'avantage, c'est que ça scale mieux que devoir faire une recherche multi champs multi table dans une seule grosse requête SQL monstrueuse. Tu peux aussi découper plus finement ta recherche en indexant mot par mot dans ces tables dédiées, plutôt qu'en indexant la totalité du contenu des champs.
[^] # Re: A essayer...
Posté par gaaaaaAab . En réponse au message SELECT * FROM matable WHERE n'importeQuelChamp = 'maValeur'. Évalué à 8.
Tu peux aussi avoir une table (valeur, type, id) triée sur valeur, ou type ferait référence au type de champ, et id pointerait sur l'id de la ligne contenant ta valeur. (c'est des noms moisis, c'est juste un exemple vite torché).
Tu chercherais valeur dans cette table et le résultat de cette recherche te permettrait immédiatement d'identifier quel(s) champ(s) de quelle(s) ligne(s) contient ta valeur.
[^] # Re: titre catastrophiste
Posté par gaaaaaAab . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 4.
aux Etats-unis ...
[^] # Re: titre catastrophiste
Posté par gaaaaaAab . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 2.
[^] # Re: titre catastrophiste
Posté par gaaaaaAab . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 2.
[^] # Re: titre catastrophiste
Posté par gaaaaaAab . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 3.
pardon m'sieur, j'ref'rais pus !
Veuillez ignorer mes messages précédents et remplacer par la mise au point suivante :
Aaaaaahh ! c'est l'apocalypse ! Le Libre est en danger ! On va tous mourir !
merci de votre attention
--> []
[^] # Re: titre catastrophiste
Posté par gaaaaaAab . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 10.
SCO affirme que les employés d'IBM qui ont contribué à Linux sont les même que ceux qui avaient accès au code d'Unix, et que donc le noyau Linux est un derivative work d'Unix.
Rien de tel pour les *BSD (qui sont bien des unix, mais pas dans le périmètre de la plainte de SCO)
Ne rentrons pas dans le détail de la qualité de l'argument, tout a été soigneusement démonté à l'époque. Relisez groklaw comme suggéré dans un autre commentaire. Il serait temps de laisser ce troll mourir ;)
[^] # Re: titre catastrophiste
Posté par gaaaaaAab . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 2.
certes. Et ? C'est impossible ?
ou alors j'ai loupé quelque chose cette été !!!
ouais, mais c'était pas cet été. Depuis quelques temps déjà, Debian expérimente l'intégration d'autres noyaux que Linux. Y a eu une Debian/Hurd, des Debian/BSD.
Il me semble que c'est d'ailleurs pour ça que les packages du noyau (autrefois kernel-2.6*) ont été renommé en linux-image-2.6*.
sinon, je l'ai peut-être mal dit dans mon commentaire, mais pour moi, le vraiment pire qui pourrait arriver serait de devoir ré écrire des bouts de noyau. Maintenant, la probabilité qu'on en arrive jusque là est vraiment très faible, et vraiment pas à court/moyen terme.
Dans l'absolu, je prétend aussi que la fin du noyau Linux ne signe pas la fin du logiciel libre, et ça, ça me parait difficilement contestable.
Pour finir, c'est une histoire qui va se régler entre SCO, Novell, IBM, Redhat, ... Ca prendra du temps parce que les machins légaux entre grosses boites prennent toujours du temps, mais je serais vraiment surpris que ça sorte un jour de ce périmètre.
C'est simplement le titre du journal que je remet en cause.
# titre catastrophiste
Posté par gaaaaaAab . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 4.
Le pire qui pourrait arriver, c'est que les développeurs du noyau Linux soient obligés de réécrire des bouts du noyau. C'est tout.
Soyons ultra pessimistes, y a plus le droit d'utiliser Linux du tout, ça sera l'occasion de se pencher sérieusement sur debian/bsd !
bref, déjà que je ne me faisais pas trop de soucis pour Linux, je m'en fais encore moins pour le "Libre".
[^] # Re: quelques surprise parfois
Posté par gaaaaaAab . En réponse au sondage La date de péremption des produits laitiers. Évalué à 3.
# templates
Posté par gaaaaaAab . En réponse au message Rapport en xhtml/html + svg. Évalué à 2.
[1] : http://www.cheetahtemplate.org/