Comparaison de fichiers - choix langage de programmation
13 réponses
Tittom
Bonjour,
J'ai besoin d'un outil de comparaison de fichiers, mais ces besoins
=E9tant tr=E8s sp=E9cifiques et pr=E9cis, je n'ai pas trouv=E9 mon bonheur
parmis les outils existants que j'ai trouv=E9, aussi je pense cr=E9er le
mien.
(Pour les curieux qui voudraient voir un exemple de ce que j'attends de
mon outil, c'est consultable en bas de la page suivante :
http://www.tittom.net/developpement/CompareFiles/ )
Jusqu'=E0 pr=E9sent, j'ai prototyp=E9 un truc qui marche pas mal du tout,
avec l'aide de :
- awk pour la routine de comparaison
- sort pour trier les fichiers selon les cl=E9s
- du shell pour encapsuler et encha=EEner tout =E7a
Je n'ai pas une large connaissance des outils de d=E9veloppement unix,
aussi j'ai peur d'en arriver =E0 utiliser une fourchette pour couper du
pain, ou un char d'assaut pour =E9craser un moustique, si vous voyez ce
que je veux dire :)
J'aimerais donc avoir des conseils quant au langage de d=E9veloppement
=E0 utiliser (perl ? c ? shell ? autres ?), alors j'indique ci-dessous
les caract=E9ristiques "cible" de mon outil.
- Comparaison de 2 fichiers texte au format CSV (ou assimil=E9, bref des
champs s=E9par=E9s par un caract=E8re)
- Les fichiers en question peuvent avoir + de 5000 caract=E8res par
ligne
- Les fichiers en question sont de l'ordre de 10Mo, exceptionnellement
50 ou 100Mo.
- Le principe de comparaison se rapproche d'une comparaison de tables
de bases de donn=E9es : rapprochement d'enregistrements par comparaison
de cl=E9s, puis comparaison zone =E0 zone des enregistrement communs
entre les 2 fichiers
- Production d'un rapport d=E9taill=E9 (format HTML ou CSV au choix)
explicitant quels =E9carts ont =E9t=E9 rencontr=E9s
- Possibilit=E9 d'ignorer certaines zones dans la comparaison, mais tout
en les affichant dans le rapport final.
Voilou, merci pour vos avis critiques !
--=20
Tittom
- Comparaison de 2 fichiers texte au format CSV (ou assimilé, bref des champs séparés par un caractère) - Les fichiers en question peuvent avoir + de 5000 caractères par ligne - Les fichiers en question sont de l'ordre de 10Mo, exceptionnellement 50 ou 100Mo. - Le principe de comparaison se rapproche d'une comparaison de tables de bases de données : rapprochement d'enregistrements par comparaison de clés, puis comparaison zone à zone des enregistrement communs entre les 2 fichiers - Production d'un rapport détaillé (format HTML ou CSV au choix) explicitant quels écarts ont été rencontrés - Possibilité d'ignorer certaines zones dans la comparaison, mais tout en les affichant dans le rapport final.
Perl me semble tout à fait adapté.
Dans tous les cas, il va falloir programmer pas mal pour permettre à l'utilisateur de saisir ses critères.
"Tittom" wrote in message
<1146041101.638980.137740@j33g2000cwa.googlegroups.com>:
- Comparaison de 2 fichiers texte au format CSV (ou assimilé, bref des
champs séparés par un caractère)
- Les fichiers en question peuvent avoir + de 5000 caractères par
ligne
- Les fichiers en question sont de l'ordre de 10Mo, exceptionnellement
50 ou 100Mo.
- Le principe de comparaison se rapproche d'une comparaison de tables
de bases de données : rapprochement d'enregistrements par comparaison
de clés, puis comparaison zone à zone des enregistrement communs
entre les 2 fichiers
- Production d'un rapport détaillé (format HTML ou CSV au choix)
explicitant quels écarts ont été rencontrés
- Possibilité d'ignorer certaines zones dans la comparaison, mais tout
en les affichant dans le rapport final.
Perl me semble tout à fait adapté.
Dans tous les cas, il va falloir programmer pas mal pour permettre à
l'utilisateur de saisir ses critères.
- Comparaison de 2 fichiers texte au format CSV (ou assimilé, bref des champs séparés par un caractère) - Les fichiers en question peuvent avoir + de 5000 caractères par ligne - Les fichiers en question sont de l'ordre de 10Mo, exceptionnellement 50 ou 100Mo. - Le principe de comparaison se rapproche d'une comparaison de tables de bases de données : rapprochement d'enregistrements par comparaison de clés, puis comparaison zone à zone des enregistrement communs entre les 2 fichiers - Production d'un rapport détaillé (format HTML ou CSV au choix) explicitant quels écarts ont été rencontrés - Possibilité d'ignorer certaines zones dans la comparaison, mais tout en les affichant dans le rapport final.
Perl me semble tout à fait adapté.
Dans tous les cas, il va falloir programmer pas mal pour permettre à l'utilisateur de saisir ses critères.
Tittom
Nicolas George wrote:
Perl me semble tout à fait adapté.
Ok, peux-tu m'indiquer s'il te semble mieux adapté que awk et pourquoi ? Je voudrais être sûr de comprendre pourquoi l'un serait mieux adapté que l'autre, ou inversement :)
Dans tous les cas, il va falloir programmer pas mal pour permettre à l'utilisateur de saisir ses critères.
J'ai oublié de préciser que mon outil s'utilise en ligne de commande, les critères seront définis dans des fichiers de configuration. C'est du pur mode batch, l'objectif étant de faire comparer les fichiers par la machine la nuit, pour analyser les résultats le jour.
Merci pour ta réponse.
Nicolas George wrote:
Perl me semble tout à fait adapté.
Ok, peux-tu m'indiquer s'il te semble mieux adapté que awk et pourquoi
? Je voudrais être sûr de comprendre pourquoi l'un serait mieux
adapté que l'autre, ou inversement :)
Dans tous les cas, il va falloir programmer pas mal pour permettre à
l'utilisateur de saisir ses critères.
J'ai oublié de préciser que mon outil s'utilise en ligne de commande,
les critères seront définis dans des fichiers de configuration. C'est
du pur mode batch, l'objectif étant de faire comparer les fichiers par
la machine la nuit, pour analyser les résultats le jour.
Ok, peux-tu m'indiquer s'il te semble mieux adapté que awk et pourquoi ? Je voudrais être sûr de comprendre pourquoi l'un serait mieux adapté que l'autre, ou inversement :)
Dans tous les cas, il va falloir programmer pas mal pour permettre à l'utilisateur de saisir ses critères.
J'ai oublié de préciser que mon outil s'utilise en ligne de commande, les critères seront définis dans des fichiers de configuration. C'est du pur mode batch, l'objectif étant de faire comparer les fichiers par la machine la nuit, pour analyser les résultats le jour.
Merci pour ta réponse.
Nicolas George
"Tittom" wrote in message :
Ok, peux-tu m'indiquer s'il te semble mieux adapté que awk et pourquoi ? Je voudrais être sûr de comprendre pourquoi l'un serait mieux adapté que l'autre, ou inversement :)
awk est extrêmement optimisé pour la tâche particulière de filtrage de fichier ligne par ligne, et ça se ressent au niveau des structures de contrôle, et des possibilités d'interaction explicite avec le système.
D'autre part, les structures de données sont plus limitées, en particulier par l'absence d'un équivalent des références de perl.
J'ai oublié de préciser que mon outil s'utilise en ligne de commande, les critères seront définis dans des fichiers de configuration. C'est du pur mode batch, l'objectif étant de faire comparer les fichiers par la machine la nuit, pour analyser les résultats le jour.
Même comme ça, il faut une syntaxe pour décrire les critères, et un interpréteur pour cette syntaxe : ça ne se fera pas tout seul, à moins d'utiliser l'interpréteur du langage lui-même.
"Tittom" wrote in message
<1146055446.600659.126930@v46g2000cwv.googlegroups.com>:
Ok, peux-tu m'indiquer s'il te semble mieux adapté que awk et pourquoi
? Je voudrais être sûr de comprendre pourquoi l'un serait mieux
adapté que l'autre, ou inversement :)
awk est extrêmement optimisé pour la tâche particulière de filtrage de
fichier ligne par ligne, et ça se ressent au niveau des structures de
contrôle, et des possibilités d'interaction explicite avec le système.
D'autre part, les structures de données sont plus limitées, en particulier
par l'absence d'un équivalent des références de perl.
J'ai oublié de préciser que mon outil s'utilise en ligne de commande,
les critères seront définis dans des fichiers de configuration. C'est
du pur mode batch, l'objectif étant de faire comparer les fichiers par
la machine la nuit, pour analyser les résultats le jour.
Même comme ça, il faut une syntaxe pour décrire les critères, et un
interpréteur pour cette syntaxe : ça ne se fera pas tout seul, à moins
d'utiliser l'interpréteur du langage lui-même.
Ok, peux-tu m'indiquer s'il te semble mieux adapté que awk et pourquoi ? Je voudrais être sûr de comprendre pourquoi l'un serait mieux adapté que l'autre, ou inversement :)
awk est extrêmement optimisé pour la tâche particulière de filtrage de fichier ligne par ligne, et ça se ressent au niveau des structures de contrôle, et des possibilités d'interaction explicite avec le système.
D'autre part, les structures de données sont plus limitées, en particulier par l'absence d'un équivalent des références de perl.
J'ai oublié de préciser que mon outil s'utilise en ligne de commande, les critères seront définis dans des fichiers de configuration. C'est du pur mode batch, l'objectif étant de faire comparer les fichiers par la machine la nuit, pour analyser les résultats le jour.
Même comme ça, il faut une syntaxe pour décrire les critères, et un interpréteur pour cette syntaxe : ça ne se fera pas tout seul, à moins d'utiliser l'interpréteur du langage lui-même.
Jusqu'à présent, j'ai prototypé un truc qui marche pas mal du tout, avec l'aide de : - awk pour la routine de comparaison - sort pour trier les fichiers selon les clés - du shell pour encapsuler et enchaîner tout ça
Je n'ai pas une large connaissance des outils de développement unix, aussi j'ai peur d'en arriver à utiliser une fourchette pour couper du pain, ou un char d'assaut pour écraser un moustique, si vous voyez ce que je veux dire :)
J'aimerais donc avoir des conseils quant au langage de développement à utiliser (perl ? c ? shell ? autres ?), alors j'indique ci-dessous les caractéristiques "cible" de mon outil.
Perso, je n'utiliserais pas C (trop de développement) ni le shell sinon pour servir de glu entre 2 ou 3 programmes (probablement trop coûteux en ressources et pas vraiment adapté). J'utiliserais un langage de script comme Ruby, je dis ça parce que j'aime bien Ruby mais on doit faire la même chose en Perl. Je ne connais pas assez awk pour juger, mais il me semble peu adapté, il est principalement basé sur les expressions régulières et il n'est pas évident que tu en aies beaucoup besoin. Un langage de script comme Ruby et Perl donnerait plus de souplesse. N'oublie pas de regarder la commande 'uniq', ça pourrait te servir.
Comme tu l'as remarqué, le problème peut être résolu par l'algèbre relationnelle, créer des tables SQL serait peut-être un peu marteau-pilon, mais regarde : http://www.linux.it/~carlos/nosql/current-doc/NoSQL.html Ca pourrait être une solution.
Jusqu'à présent, j'ai prototypé un truc qui marche pas mal du tout,
avec l'aide de :
- awk pour la routine de comparaison
- sort pour trier les fichiers selon les clés
- du shell pour encapsuler et enchaîner tout ça
Je n'ai pas une large connaissance des outils de développement unix,
aussi j'ai peur d'en arriver à utiliser une fourchette pour couper du
pain, ou un char d'assaut pour écraser un moustique, si vous voyez ce
que je veux dire :)
J'aimerais donc avoir des conseils quant au langage de développement
à utiliser (perl ? c ? shell ? autres ?), alors j'indique ci-dessous
les caractéristiques "cible" de mon outil.
Perso, je n'utiliserais pas C (trop de développement) ni le shell sinon
pour servir de glu entre 2 ou 3 programmes (probablement trop coûteux
en ressources et pas vraiment adapté).
J'utiliserais un langage de script comme Ruby, je dis ça parce que
j'aime bien Ruby mais on doit faire la même chose en Perl.
Je ne connais pas assez awk pour juger, mais il me semble peu adapté, il
est principalement basé sur les expressions régulières et il n'est pas
évident que tu en aies beaucoup besoin. Un langage de script comme Ruby
et Perl donnerait plus de souplesse.
N'oublie pas de regarder la commande 'uniq', ça pourrait te servir.
Comme tu l'as remarqué, le problème peut être résolu par l'algèbre
relationnelle, créer des tables SQL serait peut-être un peu
marteau-pilon, mais regarde :
http://www.linux.it/~carlos/nosql/current-doc/NoSQL.html
Ca pourrait être une solution.
Jusqu'à présent, j'ai prototypé un truc qui marche pas mal du tout, avec l'aide de : - awk pour la routine de comparaison - sort pour trier les fichiers selon les clés - du shell pour encapsuler et enchaîner tout ça
Je n'ai pas une large connaissance des outils de développement unix, aussi j'ai peur d'en arriver à utiliser une fourchette pour couper du pain, ou un char d'assaut pour écraser un moustique, si vous voyez ce que je veux dire :)
J'aimerais donc avoir des conseils quant au langage de développement à utiliser (perl ? c ? shell ? autres ?), alors j'indique ci-dessous les caractéristiques "cible" de mon outil.
Perso, je n'utiliserais pas C (trop de développement) ni le shell sinon pour servir de glu entre 2 ou 3 programmes (probablement trop coûteux en ressources et pas vraiment adapté). J'utiliserais un langage de script comme Ruby, je dis ça parce que j'aime bien Ruby mais on doit faire la même chose en Perl. Je ne connais pas assez awk pour juger, mais il me semble peu adapté, il est principalement basé sur les expressions régulières et il n'est pas évident que tu en aies beaucoup besoin. Un langage de script comme Ruby et Perl donnerait plus de souplesse. N'oublie pas de regarder la commande 'uniq', ça pourrait te servir.
Comme tu l'as remarqué, le problème peut être résolu par l'algèbre relationnelle, créer des tables SQL serait peut-être un peu marteau-pilon, mais regarde : http://www.linux.it/~carlos/nosql/current-doc/NoSQL.html Ca pourrait être une solution.
-- http://patrick.davalan.free.fr/
Tittom
Nicolas George wrote:
awk est extrêmement optimisé pour la tâche particulière de filtra ge de fichier ligne par ligne, et ça se ressent au niveau des structures de contrôle, et des possibilités d'interaction explicite avec le systè me.
Quand tu dis que "ça se ressent", c'est que les structures de contrôle et possibilités d'interaction explicite avec le système risquent d'induire des pb de perf, alors que ce n'est pas le cas en perl ?
D'autre part, les structures de données sont plus limitées, en partic ulier par l'absence d'un équivalent des références de perl.
Ca ne devrait pas me gêner beaucoup, j'ai principalement des chaines alphanumériques. Mais c'est une souplesse à prendre en compte en effet !
Je sens que je vais me mettre à perl :)
J'ai oublié de préciser que mon outil s'utilise en ligne de command e, les critères seront définis dans des fichiers de configuration. C'e st du pur mode batch, l'objectif étant de faire comparer les fichiers par la machine la nuit, pour analyser les résultats le jour.
Même comme ça, il faut une syntaxe pour décrire les critères, et un interpréteur pour cette syntaxe : ça ne se fera pas tout seul, à mo ins d'utiliser l'interpréteur du langage lui-même.
Je pensais imposer une forme de ce type dans les fichiers de configuration : # liste des zones clé zone1;zone2;zone3 # liste des zones à ne pas comparer zone8;zone5
C'est à peu près tout ce dont j'ai besoin. Bref cette partie là ne m'inquiète pas trop.
Merci encore pour tes lumières.
Nicolas George wrote:
awk est extrêmement optimisé pour la tâche particulière de filtra ge de
fichier ligne par ligne, et ça se ressent au niveau des structures de
contrôle, et des possibilités d'interaction explicite avec le systè me.
Quand tu dis que "ça se ressent", c'est que les structures de
contrôle et possibilités d'interaction explicite avec le système
risquent d'induire des pb de perf, alors que ce n'est pas le cas en
perl ?
D'autre part, les structures de données sont plus limitées, en partic ulier
par l'absence d'un équivalent des références de perl.
Ca ne devrait pas me gêner beaucoup, j'ai principalement des chaines
alphanumériques.
Mais c'est une souplesse à prendre en compte en effet !
Je sens que je vais me mettre à perl :)
J'ai oublié de préciser que mon outil s'utilise en ligne de command e,
les critères seront définis dans des fichiers de configuration. C'e st
du pur mode batch, l'objectif étant de faire comparer les fichiers par
la machine la nuit, pour analyser les résultats le jour.
Même comme ça, il faut une syntaxe pour décrire les critères, et un
interpréteur pour cette syntaxe : ça ne se fera pas tout seul, à mo ins
d'utiliser l'interpréteur du langage lui-même.
Je pensais imposer une forme de ce type dans les fichiers de
configuration :
# liste des zones clé
zone1;zone2;zone3
# liste des zones à ne pas comparer
zone8;zone5
C'est à peu près tout ce dont j'ai besoin. Bref cette partie là ne
m'inquiète pas trop.
awk est extrêmement optimisé pour la tâche particulière de filtra ge de fichier ligne par ligne, et ça se ressent au niveau des structures de contrôle, et des possibilités d'interaction explicite avec le systè me.
Quand tu dis que "ça se ressent", c'est que les structures de contrôle et possibilités d'interaction explicite avec le système risquent d'induire des pb de perf, alors que ce n'est pas le cas en perl ?
D'autre part, les structures de données sont plus limitées, en partic ulier par l'absence d'un équivalent des références de perl.
Ca ne devrait pas me gêner beaucoup, j'ai principalement des chaines alphanumériques. Mais c'est une souplesse à prendre en compte en effet !
Je sens que je vais me mettre à perl :)
J'ai oublié de préciser que mon outil s'utilise en ligne de command e, les critères seront définis dans des fichiers de configuration. C'e st du pur mode batch, l'objectif étant de faire comparer les fichiers par la machine la nuit, pour analyser les résultats le jour.
Même comme ça, il faut une syntaxe pour décrire les critères, et un interpréteur pour cette syntaxe : ça ne se fera pas tout seul, à mo ins d'utiliser l'interpréteur du langage lui-même.
Je pensais imposer une forme de ce type dans les fichiers de configuration : # liste des zones clé zone1;zone2;zone3 # liste des zones à ne pas comparer zone8;zone5
C'est à peu près tout ce dont j'ai besoin. Bref cette partie là ne m'inquiète pas trop.
Merci encore pour tes lumières.
Tittom
Harpo wrote:
Perso, je n'utiliserais pas C (trop de développement) ni le shell sinon pour servir de glu entre 2 ou 3 programmes (probablement trop coûteux en ressources et pas vraiment adapté).
En effet, le C commence par un "c", comme char d'assaut ;) Côté shell j'avais commencé mon prototype avec, mais j'ai vite abandonné, je dirais même "vraiment pas adapté" plutôt que "pas vraiment adapté" :)
J'utiliserais un langage de script comme Ruby, je dis ça parce que j'aime bien Ruby mais on doit faire la même chose en Perl.
Je ne connais pas ruby. "man ruby" me jette, je suppose donc que je ne l'ai pas par défaut. Je vais quand même regarder ce que c'est cette bête.
[...] N'oublie pas de regarder la commande 'uniq', ça pourrait te servir.
Pas forcément, je ne cherche pas à ignorer les doublons. A moins que tu penses à autre chose que les doublons ?
Comme tu l'as remarqué, le problème peut être résolu par l'algè bre relationnelle, créer des tables SQL serait peut-être un peu marteau-pilon, mais regarde : http://www.linux.it/~carlos/nosql/current-doc/NoSQL.html Ca pourrait être une solution.
Je ne connaissais pas cela, je vais regarder de près ça a l'air costaud !
Merci bien
-- Tittom
Harpo wrote:
Perso, je n'utiliserais pas C (trop de développement) ni le shell sinon
pour servir de glu entre 2 ou 3 programmes (probablement trop coûteux
en ressources et pas vraiment adapté).
En effet, le C commence par un "c", comme char d'assaut ;)
Côté shell j'avais commencé mon prototype avec, mais j'ai vite
abandonné, je dirais même "vraiment pas adapté" plutôt que "pas
vraiment adapté" :)
J'utiliserais un langage de script comme Ruby, je dis ça parce que
j'aime bien Ruby mais on doit faire la même chose en Perl.
Je ne connais pas ruby. "man ruby" me jette, je suppose donc que je ne
l'ai pas par défaut. Je vais quand même regarder ce que c'est cette
bête.
[...]
N'oublie pas de regarder la commande 'uniq', ça pourrait te servir.
Pas forcément, je ne cherche pas à ignorer les doublons. A moins que
tu penses à autre chose que les doublons ?
Comme tu l'as remarqué, le problème peut être résolu par l'algè bre
relationnelle, créer des tables SQL serait peut-être un peu
marteau-pilon, mais regarde :
http://www.linux.it/~carlos/nosql/current-doc/NoSQL.html
Ca pourrait être une solution.
Je ne connaissais pas cela, je vais regarder de près ça a l'air
costaud !
Perso, je n'utiliserais pas C (trop de développement) ni le shell sinon pour servir de glu entre 2 ou 3 programmes (probablement trop coûteux en ressources et pas vraiment adapté).
En effet, le C commence par un "c", comme char d'assaut ;) Côté shell j'avais commencé mon prototype avec, mais j'ai vite abandonné, je dirais même "vraiment pas adapté" plutôt que "pas vraiment adapté" :)
J'utiliserais un langage de script comme Ruby, je dis ça parce que j'aime bien Ruby mais on doit faire la même chose en Perl.
Je ne connais pas ruby. "man ruby" me jette, je suppose donc que je ne l'ai pas par défaut. Je vais quand même regarder ce que c'est cette bête.
[...] N'oublie pas de regarder la commande 'uniq', ça pourrait te servir.
Pas forcément, je ne cherche pas à ignorer les doublons. A moins que tu penses à autre chose que les doublons ?
Comme tu l'as remarqué, le problème peut être résolu par l'algè bre relationnelle, créer des tables SQL serait peut-être un peu marteau-pilon, mais regarde : http://www.linux.it/~carlos/nosql/current-doc/NoSQL.html Ca pourrait être une solution.
Je ne connaissais pas cela, je vais regarder de près ça a l'air costaud !
Merci bien
-- Tittom
Harpo
Tittom wrote:
Je ne connais pas ruby. "man ruby" me jette, je suppose donc que je ne l'ai pas par défaut. Je vais quand même regarder ce que c'est cette bête.
Ca vaut le coup d'oeil.
[...] N'oublie pas de regarder la commande 'uniq', ça pourrait te servir.
Pas forcément, je ne cherche pas à ignorer les doublons. A moins que tu penses à autre chose que les doublons ?
Je pensais que si tu avais 2 fichiers à comparer tu aurais pu ajouter un champ identifiant le fichier dans chaque record de ce fichier, trier les 2 fichiers sur une même clé en même temps pour donner un seul fichier résultat contenant les 2, ou s'ils sont déjà triés, utiliser 'sort --merge' et ensuite utiliser uniq pour printer les lignes dupliquées, Cela dépends de ce que tu as à faire plus précisément. mais si ça convient, ce n'est pas long à faire même si c'est un peu bourrin.
Tittom wrote:
Je ne connais pas ruby. "man ruby" me jette, je suppose donc que je ne
l'ai pas par défaut. Je vais quand même regarder ce que c'est cette
bête.
Ca vaut le coup d'oeil.
[...]
N'oublie pas de regarder la commande 'uniq', ça pourrait te servir.
Pas forcément, je ne cherche pas à ignorer les doublons. A moins que
tu penses à autre chose que les doublons ?
Je pensais que si tu avais 2 fichiers à comparer tu aurais pu ajouter
un champ identifiant le fichier dans chaque record de ce fichier, trier
les 2 fichiers sur une même clé en même temps pour donner un seul
fichier résultat contenant les 2, ou s'ils sont déjà triés, utiliser
'sort --merge' et ensuite utiliser uniq pour printer les lignes
dupliquées,
Cela dépends de ce que tu as à faire plus précisément. mais si ça
convient, ce n'est pas long à faire même si c'est un peu bourrin.
Je ne connais pas ruby. "man ruby" me jette, je suppose donc que je ne l'ai pas par défaut. Je vais quand même regarder ce que c'est cette bête.
Ca vaut le coup d'oeil.
[...] N'oublie pas de regarder la commande 'uniq', ça pourrait te servir.
Pas forcément, je ne cherche pas à ignorer les doublons. A moins que tu penses à autre chose que les doublons ?
Je pensais que si tu avais 2 fichiers à comparer tu aurais pu ajouter un champ identifiant le fichier dans chaque record de ce fichier, trier les 2 fichiers sur une même clé en même temps pour donner un seul fichier résultat contenant les 2, ou s'ils sont déjà triés, utiliser 'sort --merge' et ensuite utiliser uniq pour printer les lignes dupliquées, Cela dépends de ce que tu as à faire plus précisément. mais si ça convient, ce n'est pas long à faire même si c'est un peu bourrin.
Laurent Deniau
Nicolas George wrote:
"Tittom" wrote in message :
Ok, peux-tu m'indiquer s'il te semble mieux adapté que awk et pourquoi ? Je voudrais être sûr de comprendre pourquoi l'un serait mieux adapté que l'autre, ou inversement :)
awk est extrêmement optimisé pour la tâche particulière de filtrage de fichier ligne par ligne,
pas seulement ligne par ligne. N'importe quelle expression rationnelle dynamique ou non peut separer les "records" et les "fields".
et ça se ressent au niveau des structures de contrôle,
par exemple?
et des possibilités d'interaction explicite avec le système.
Sans aucun doute, ce n'est pas fait pour du sysadmin mais pour traiter des fichiers textes, domaine dans lequel il excelle.
D'autre part, les structures de données sont plus limitées, en particulier par l'absence d'un équivalent des références de perl.
awk possede les tableaux associatifs multidimensionnels (equivalent des tables de haschage de perl avec ou sans reference). C'est ce qu'il y a de plus flexible et polyvalent. Par contre ce n'est pas toujours ce qui est le plus rapide ou le moins consomateur de memoire.
Les criteres en faveur de perl sont plutot la possibilite de commencer petit et de voir grand ensuite, d'utiliser les innombrables modules disponibles, sa rapidite et le cas echeant son mode awk. En revanche, awk est beaucoup plus simple. Il toujours possible de commencer en awk (si on se sens plus a l'aise avec) et tout traduire en perl ensuite (je crois meme qu'il y a un outil qui fait ca automatiquement).
a+, ld.
Nicolas George wrote:
"Tittom" wrote in message
<1146055446.600659.126930@v46g2000cwv.googlegroups.com>:
Ok, peux-tu m'indiquer s'il te semble mieux adapté que awk et pourquoi
? Je voudrais être sûr de comprendre pourquoi l'un serait mieux
adapté que l'autre, ou inversement :)
awk est extrêmement optimisé pour la tâche particulière de filtrage de
fichier ligne par ligne,
pas seulement ligne par ligne. N'importe quelle expression rationnelle
dynamique ou non peut separer les "records" et les "fields".
et ça se ressent au niveau des structures de
contrôle,
par exemple?
et des possibilités d'interaction explicite avec le système.
Sans aucun doute, ce n'est pas fait pour du sysadmin mais pour traiter
des fichiers textes, domaine dans lequel il excelle.
D'autre part, les structures de données sont plus limitées, en particulier
par l'absence d'un équivalent des références de perl.
awk possede les tableaux associatifs multidimensionnels (equivalent des
tables de haschage de perl avec ou sans reference). C'est ce qu'il y a
de plus flexible et polyvalent. Par contre ce n'est pas toujours ce qui
est le plus rapide ou le moins consomateur de memoire.
Les criteres en faveur de perl sont plutot la possibilite de commencer
petit et de voir grand ensuite, d'utiliser les innombrables modules
disponibles, sa rapidite et le cas echeant son mode awk. En revanche,
awk est beaucoup plus simple. Il toujours possible de commencer en awk
(si on se sens plus a l'aise avec) et tout traduire en perl ensuite (je
crois meme qu'il y a un outil qui fait ca automatiquement).
Ok, peux-tu m'indiquer s'il te semble mieux adapté que awk et pourquoi ? Je voudrais être sûr de comprendre pourquoi l'un serait mieux adapté que l'autre, ou inversement :)
awk est extrêmement optimisé pour la tâche particulière de filtrage de fichier ligne par ligne,
pas seulement ligne par ligne. N'importe quelle expression rationnelle dynamique ou non peut separer les "records" et les "fields".
et ça se ressent au niveau des structures de contrôle,
par exemple?
et des possibilités d'interaction explicite avec le système.
Sans aucun doute, ce n'est pas fait pour du sysadmin mais pour traiter des fichiers textes, domaine dans lequel il excelle.
D'autre part, les structures de données sont plus limitées, en particulier par l'absence d'un équivalent des références de perl.
awk possede les tableaux associatifs multidimensionnels (equivalent des tables de haschage de perl avec ou sans reference). C'est ce qu'il y a de plus flexible et polyvalent. Par contre ce n'est pas toujours ce qui est le plus rapide ou le moins consomateur de memoire.
Les criteres en faveur de perl sont plutot la possibilite de commencer petit et de voir grand ensuite, d'utiliser les innombrables modules disponibles, sa rapidite et le cas echeant son mode awk. En revanche, awk est beaucoup plus simple. Il toujours possible de commencer en awk (si on se sens plus a l'aise avec) et tout traduire en perl ensuite (je crois meme qu'il y a un outil qui fait ca automatiquement).
a+, ld.
Nicolas George
Laurent Deniau wrote in message <e2o62c$8fd$:
awk possede les tableaux associatifs multidimensionnels (equivalent des tables de haschage de perl avec ou sans reference). C'est ce qu'il y a de plus flexible et polyvalent.
Non, ça ne suffit pas, parce que les tableaux n'ont pas la citoyenneté de première classe, ce qui est vraiment indispensable pour faire de la programmation structurée, par exemple simuler des structures.
Laurent Deniau wrote in message <e2o62c$8fd$1@sunnews.cern.ch>:
awk possede les tableaux associatifs multidimensionnels (equivalent des
tables de haschage de perl avec ou sans reference). C'est ce qu'il y a
de plus flexible et polyvalent.
Non, ça ne suffit pas, parce que les tableaux n'ont pas la citoyenneté de
première classe, ce qui est vraiment indispensable pour faire de la
programmation structurée, par exemple simuler des structures.
awk possede les tableaux associatifs multidimensionnels (equivalent des tables de haschage de perl avec ou sans reference). C'est ce qu'il y a de plus flexible et polyvalent.
Non, ça ne suffit pas, parce que les tableaux n'ont pas la citoyenneté de première classe, ce qui est vraiment indispensable pour faire de la programmation structurée, par exemple simuler des structures.
Paul Gaborit
À (at) 26 Apr 2006 01:45:01 -0700, "Tittom" écrivait (wrote):
J'ai besoin d'un outil de comparaison de fichiers, mais ces besoins étant très spécifiques et précis, je n'ai pas trouvé mon bonheur parmis les outils existants que j'ai trouvé, aussi je pense créer le mien.
Vous devriez jeter un oeil à la commande 'join'. Combinée avec quelques autres commandes de bases, ça doit pouvoir faire des trucs pas mal.
Sinon, pour écrire cela, Perl me semble tout à fait adapté.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
J'ai besoin d'un outil de comparaison de fichiers, mais ces besoins
étant très spécifiques et précis, je n'ai pas trouvé mon bonheur
parmis les outils existants que j'ai trouvé, aussi je pense créer le
mien.
Vous devriez jeter un oeil à la commande 'join'. Combinée avec
quelques autres commandes de bases, ça doit pouvoir faire des trucs
pas mal.
Sinon, pour écrire cela, Perl me semble tout à fait adapté.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 26 Apr 2006 01:45:01 -0700, "Tittom" écrivait (wrote):
J'ai besoin d'un outil de comparaison de fichiers, mais ces besoins étant très spécifiques et précis, je n'ai pas trouvé mon bonheur parmis les outils existants que j'ai trouvé, aussi je pense créer le mien.
Vous devriez jeter un oeil à la commande 'join'. Combinée avec quelques autres commandes de bases, ça doit pouvoir faire des trucs pas mal.
Sinon, pour écrire cela, Perl me semble tout à fait adapté.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
