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
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.
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.
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.
Nicolas George
Laurent Deniau wrote in message <e2o7e9$9q4$:
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.
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.
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.
starlord
Tittom a écrit le 26/04/2006 à 10h45 :
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
Bonjour,
Ce sujet est maintenant un peu vieux, mais j'ai quelque chose de similaire à faire. As-tu avancé sur le sujet ? Si oui, serais-tu prêt à partager ton expérience ? Merci !
Tittom a écrit le 26/04/2006 à 10h45 :
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
Bonjour,
Ce sujet est maintenant un peu vieux, mais j'ai quelque chose de similaire à faire. As-tu avancé sur le sujet ? Si oui, serais-tu prêt à partager ton expérience ?
Merci !
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
Bonjour,
Ce sujet est maintenant un peu vieux, mais j'ai quelque chose de similaire à faire. As-tu avancé sur le sujet ? Si oui, serais-tu prêt à partager ton expérience ? Merci !
