Bonjour,

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.

(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'à 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.

- 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.


Voilou, merci pour vos avis critiques !
--
Tittom

"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.

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.

"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.

Tittom wrote:

> http://www.tittom.net/developpement/CompareFiles/ )
>
> 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/cu...doc/NoSQL.html
Ca pourrait être une solution.

--
http://patrick.davalan.free.fr/

Nicolas George wrote:
> 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.

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 particulier
> 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 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.

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.

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/cu...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

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.

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).

a+, ld.

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.

À (at) 26 Apr 2006 01:45:01 -0700,
"Tittom" <tittom@free.fr> é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/>

Nicolas George wrote:
> 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.

Ce n'est pas une necessite, en particulier pas sur les petits projets
que awk vise. Et cela peut etre simule au prix d'une baisse de performance.

a+, ld.

Laurent Deniau wrote in message <e2o7e9$9q4$1@sunnews.cern.ch>:
> Ce n'est pas une necessite, en particulier pas sur les petits projets
> que awk vise. Et cela peut etre simule au prix d'une baisse de performance.

Oui, et on peut tout faire avec une machine de Turing. C'est la vitesse de
développement et la maintenabilité qui en prend un coup.