[bash] Comparer deux fichiers csv

Bonjour à tous,

Comme indiqué dans le titre, j'essaye de comparer deux fichiers CSV, malheureusement, sur un des fichiers, il y a plusieurs colonnes et je ne veux comparer qu'une des colonnes. Pour être plus claire, voici les fichiers:

mac_port.csv

Citation:

---

00.1F.FF.5H.66 ; 23 (le ";" étant le délimiteur)
00.1F.FF.4J.1B ; 14

---

port.csv

Citation:

---

23

---

je voudrais comparer la deuxième colonne du premier fichier avec le deuxième fichier, et dès qu'il y a concordance, je récupère en sortie la première colonne. Malheureusement, j'y étais arrivé en PowerShell, et Bash ne me simplifie pas la tâche. J'ai tenté avec cmp, diff, mais rien qui ne me permet de faire cela.

Any ideas ?

Bonjour,

Code:

---

1 2	awk -F' ; ' 'FNR=NR{a[$2]=$1;};{if($1 in a)print a[$1]}' mac_port port 00.1F.FF.5H.66

---

Bonjour.

Possible aussi avec join :

Code:

---

1 2 3 4 5 6 7 8 9 10

[idriss@hp-dv6:~]$ cat f1.txt 23 ; dsdjksjfk 32 ; sdosf 56 ; sdsldk 23 ; sfsofksofo [idriss@hp-dv6:~]$ cat f2.txt 00.1F.FF.5H.66 ; 23 00.1F.FF.4J.1B ; 14 [idriss@hp-dv6:~]$ join -t';' -11 -22 <(sed 's/\ //g' f1.txt|sort) <(sed 's/\ //g' f2.txt|sort)|cut -d ';' -f3|sort -u 00.1F.FF.5H.66

---

Tu peux aussi bricoler avec grep :

Code:

---

1 2	[idriss@hp-dv6:~]$ grep -f <(sed 's/\ //g' f1.txt|sort|cut -d';' -f1) <(sed 's/\ //g' f2.txt|sort)|cut -d ';' -f1 00.1F.FF.5H.66

---

Mais bon, la solution de N_Bah reste plus jolie :aie:

Idriss

j'allais proposer une solution avec join sur la base des fichiers fournis par El_Cypriano

Code:

---

1 2	$ join -t';' -o'1.1' -1 2 -2 1 <(sort -t';' -k2 <(sed 's/ *//g' mac_port)) port 00.1F.FF.5H.66

---

Merci N_BaH et ok.Idriss,

Les solutions sont bonnes, mais quel est celui qui bouffe un peu de process, parce que ce n'est que le début d'un script long... trop long. Et donc, on m'a dit que "awk" était plus gourmand qu'autre chose, donc join ou grep permettrait d'être plus réactif !?

Est-ce que vous être d'accord sur cela ?

Salut,

Citation:

---

Envoyé par N_BaH

j'allais proposer une solution avec join sur la base des fichiers fournis par El_Cypriano

Code:

---

1 2	$ join -t';' -o'1.1' -1 2 -2 1 <(sort -t';' -k2 <(sed 's/ *//g' mac_port)) port 00.1F.FF.5H.66

---

---

Et si on considère qu'il y a toujours des espaces avant et après le délimiteur qui est le point virgule, et donc qu'on prenne le délimiteur par défaut (l'espace), on peut faire ceci :

Code:

---

1 2	$ join -1 3 -2 1 -o 1.1 f1 f2 00.1F.FF.5H.66

---

vu qu'il faudra, en plus du join, trier au moins un fichier, plus peut-être un ou deux sed (ça dépend du format des fichiers), je pense que awk sera moins gourmand en ressources; d'autant que peut-être tout le script pourrait être écrit en awk...

Bonsoir.

Suffit de faire des tests de perf :P

Code:

---

1 2	[idriss@hp-dv6:~]$ content=""; for i in {1..1000}; do content=$(cat f1.txt <(echo -e "$content")); done; [idriss@hp-dv6:~]$ content2=""; for i in {1..1000}; do content2=$(cat f2.txt <(echo -e "$content2")); done;

---

Pour ma version de join :

Code:

---

1 2 3 4

[idriss@hp-dv6:~]$ date +%H:%M:%S:%N;join -t';' -11 -22 <(echo -e"$content"|sed 's/\ //g'|sort) <(echo -e "$content2"|sed 's/\ //g'|sort)|cut -d ';' -f3|sort -u;date +%H:%M:%S:%N 17:46:56:957289092 00.1F.FF.5H.66 17:46:58:287069050

---

Pour ma solution avec grep :

Code:

---

1 2 3 4

[idriss@hp-dv6:~]$ date +%H:%M:%S:%N;grep -f <(echo -e "$content"|sed 's/\ //g'|sort|cut -d';' -f1) <(echo -e "$content2"|sed 's/\ //g'|sort)|cut -d ';' -f1|sort -u;date +%H:%M:%S:%N 17:49:11:036894800 00.1F.FF.5H.66 17:49:11:148334877

---

C'est rapide grep, en fait :D

Et une solution avec awk inspirée de la solution de N_Bah mais permettant d'éviter les doublons sans passer par sort :

Code:

---

awk -F' ; ' 'FNR=NR{a[$2]=$1;};{if($1 in a)t[a[$1]]=a[$1]} END {for (i in t)print t[i]}' f2.txt f1.txt

---

Voici pour le test de perf :

Code:

---

1 2 3 4

[idriss@hp-dv6:~]$ date +%H:%M:%S:%N;awk -F' ; ' 'FNR=NR{a[$2]=$1;};{if($1 in a)t[a[$1]]=a[$1]} END {for (i in t)print t[i]}' <(echo -e "$content2") <(echo -e "$content");date +%H:%M:%S:%N 17:55:11:264311606 00.1F.FF.5H.66 17:55:11:289953146

---

=> Quasi instantané également.

Pour départager grep et awk, on pourrait faire un test de perf à plus grande échelle (10 000 fois le contenu par exemple) mais bon le CPU de mon petit laptop morfle trop :mouarf:

Comme dit N_Bah, la solution awk à l'avantage de n'utiliser qu'un processus donc préférable et est probablement plus performante à plus grande échelle.

Idriss

Comme chacun y va de sa solution, j'y vais aussi:

Code:

---

1 2 3 4 5 6 7 8

$ cat initial.txt 00.1F.FF.5H.66 ; 23 00.1F.FF.4J.1B ; 14 $ cat filtre.txt 23 $ sed 's/.*/;.*&/' filtre.txt|grep -f - initial.txt |sed 's/;.*$//' 00.1F.FF.5H.66 $

---

Sur le même model que Flodelarab (:ccool:) mais en virant le grep:

Code:

---

1 2 3 4 5 6 7

$ cat initial.txt 00.1F.FF.5H.66 ; 23 00.1F.FF.4J.1B ; 14 $ cat filtre.txt 23 $ sed 's/.*/s\/;.*&\/\/p/' filtre.txt|sed -n -f - initial.txt 00.1F.FF.5H.66

---

Si on considère que le second fichier n'est pas un vrai csv et ne contient que les valeurs correspondant à la seconde et que les valeurs de la première colonne sont unique, ceci suffirait :aie:

Code:

---

grep -f f2.txt f1.txt | awk -F " ; " '{print $1}'

---

Citation:

---

Sur le même model que Flodelarab () mais en virant le grep:
Code :

$ cat initial.txt
00.1F.FF.5H.66 ; 23
00.1F.FF.4J.1B ; 14
$ cat filtre.txt
23
$ sed 's/.*/s\/;.*&\/\/p/' filtre.txt|sed -n -f - initial.txt
00.1F.FF.5H.66

---

Joli! J'en remets une couche: (moins de "\" )

Code:

---

sed 's@.*@s/;.*&//;t bon;d;:bon;p@' filtre.txt|sed -n -f - initial.txt

---

Citation:

---

Envoyé par ok.Idriss

Si on considère que le second fichier n'est pas un vrai csv et ne contient que les valeurs correspondant à la seconde et que les valeurs de la première colonne sont unique, ceci suffirait :aie:

Code:

---

grep -f f2.txt f1.txt | awk -F " ; " '{print $1}'

---

---

Euh sauf si le premier champ contient 23

Pas faux :oops:

Bien vu :ccool:

Citation:

---

Envoyé par Flodelarab

Joli! J'en remets une couche: (moins de "\" )

Code:

---

sed 's@.*@s/;.*&//;t bon;d;:bon;p@' filtre.txt|sed -n -f - initial.txt

---

---

Une surcouche :aie:

Code:

---

xargs -a filtre.txt -ITT sed -n "s/;.*TT//p" initial.txt

---

Citation:

---

Envoyé par N_BaH

Bonjour,

Code:

---

1 2	awk -F' ; ' 'FNR=NR{a[$2]=$1;};{if($1 in a)print a[$1]}' mac_port port 00.1F.FF.5H.66

---

---

Je dirais plutôt:

Code:

---

awk -F' ; ' 'FNR==NR{a[$2]=$1;next}a[$1]{print a[$1]}' mac_port port

---

FNR=NR est toujours vrai. Il manque aussi, me semble-t-il, l'instruction next non?

Non. FNR et NR ne sont égaux que pour le premier fichier en entrée. Pour le second, NR retombe à 0 et FNR poursuit sa route.

C'est pour cela que next est inutile et que la seconde accolade n'a pas besoin de condition. En effet, l'instruction "for i in ..." s'applique aux indices et pas aux valeurs. Aucun indice du tableau n'est un port puisque ce sont les adresses.

Par contre, j'aurais mis "FNR==NR" et pas "="

Citation:

---

Envoyé par El_Cypriano

Merci N_BaH et ok.Idriss,

Les solutions sont bonnes, mais quel est celui qui bouffe un peu de process, parce que ce n'est que le début d'un script long... trop long. Et donc, on m'a dit que "awk" était plus gourmand qu'autre chose, donc join ou grep permettrait d'être plus réactif !?

Est-ce que vous être d'accord sur cela ?

---

Cela peut dépendre beaucoup de ton contexte, comme par exemple, quel sera la quantité de valeur dans ton 2éme fichier, juste une ???
Ainsi que la quantité du 1er fichier ?
Le but est de savoir si on doit s'arranger pour traiter tes fichiers en une seule passe (ici c'est le cas pour toutes les méthodes présentées car on a q'une seule donner à traiter dans le 2éme fichier sinon, plusieurs solutions ne sont pas bonnes du tout comme par exemple celle que j'ai proposée avec le xargs et le sed) et le awk peut être avantageux dans ce type de cas.

Citation:

---

Non. FNR et NR ne sont égaux que pour le premier fichier en entrée.

---

le problème n'est pas là, mais dans mon oubli d'un second =

Code:

---

1 2	= #est une assignation, et donc toujours vrai == #est un opérateur de test

---

Le tout est de se comprendre. Nous sommes tous les 3 d'accord.

Citation:

---

Les solutions sont bonnes, mais quel est celui qui bouffe un peu de process, parce que ce n'est que le début d'un script long... trop long. Et donc, on m'a dit que "awk" était plus gourmand qu'autre chose, donc join ou grep permettrait d'être plus réactif !?

Est-ce que vous être d'accord sur cela ?

---

Une expérience perso:

• fonctions natives de awk: Echec (100x trop long)
• grep:
  real 0m43.304s
  user 0m24.802s
  sys 0m14.385s
• grep -q
  real 0m8.246s
  user 0m2.262s
  sys 0m4.277s

Donc, ma conclusion a été franchement contre awk. Son point fort est le traitement par champ. Sinon, je prends autre chose.
Il faut dire que je traitais un gros dictionnaire.

Citation:

---

Envoyé par Flodelarab

Non. FNR et NR ne sont égaux que pour le premier fichier en entrée. Pour le second, NR retombe à 0 et FNR poursuit sa route.

C'est pour cela que next est inutile et que la seconde accolade n'a pas besoin de condition. En effet, l'instruction "for i in ..." s'applique aux indices et pas aux valeurs. Aucun indice du tableau n'est un port puisque ce sont les adresses.

---

:koi:

Les indices sont précisément les numéros de port.($2 deuxième champ du premier fichier lu par awk).

La condition de la deuxième instruction est indispensable. C'est elle qui permet d'imprimer les adresses (valeur du tableau a) ayant un numéro de port comme indice. La condition proposée par N_BaH était correcte. Elle pouvait aussi simplement s'écrire a[$1] qui s'évalue à TRUE si cet indice (port) existe dans le premier fichier.

Enfin, l'instruction next est également indispensable pour "boucler" sur la première instruction et sa condition FNR==NR et d'ainsi rester sur le premier fichier. Sans elle, la deuxième instruction serait inutilement exécutée pour toutes les lignes du premier fichier. C'est la raison pour laquelle ok.Idriss a dû supprimer les doublons dans son test plus haut.

Quant à la rapidité d'exécution, tout dépend du contexte et de la taille des fichiers. Y-a-t-il plusieurs lignes dans le fichier port? Risque t'on de retrouver des numéros de port dans les adresses mac (grep inutilisable)?

Pourquoi grep serait-il inutilisable ???
Rien n'empêche de réécrire à la volée le fichier de port pour créer le bon pattern et de dire au grep de prendre comme fichier de pattern, l'entrée standard (voir l'une des solution de flodelarab)

Citation:

---

Envoyé par disedorgue

Pourquoi grep serait-il inutilisable ???
Rien n'empêche de réécrire à la volée le fichier de port pour créer le bon pattern et de dire au grep de prendre comme fichier de pattern, l'entrée standard (voir l'une des solution de flodelarab)

---

Certes mais à quel coût? Combien de pipe ou sous-process? Ça me rappelle une réponse un brin humoristique d'un modérateur du forum unix.com

Citation:

---

Also, whenever you're doing grep | grep | awk | kitchen | sink, you should just replace it all with one simple awk command.

---

;)

On est d'accord sur le fond, ici, on aurait:

Citation:

---

sed | grep | cut

---

Techniquement, on ne parserait qu'une seule fois le fichier mac_port.
Pour le fichier port, on le parse au moins une fois pour la mise en forme. puis formatage de la sorti par cut. Bizarrement, un grep+cut est aussi rapide qu'un sed qui fait la même chose (tout au moins sur des fichiers de mille lignes environ).

En awk, on est a peu près équivalent, car il est obligé de lire au moins un fois chaque fichier, il y a donc au moins une mise en forme (donnée de parsing) et les données à parser + la mise en forme pour la sortie.

Après, selon la regex, il n'est pas impossible que la méthode par le grep puisse prendre la main...

Citation:

---

Envoyé par ripat

Les indices sont précisément les numéros de port.($2 deuxième champ du premier fichier lu par awk).

---

Levons l'ambiguïté: quand on se trouve dans la deuxième accolade pour le premier fichier, a[$1] utilise pour indice les adresses (00.1F.FF.5H.66) et n'a aucune chance de correspondre.

Citation:

---

Envoyé par ripat

La condition de la deuxième instruction est indispensable.

---

Elle est inutile. Que la confrontation ait lieu dans l'accolade ou avant l'accolade ne m'empêche pas de dormir.

Citation:

---

Envoyé par ripat

La condition proposée par N_BaH était correcte. Elle pouvait aussi simplement s'écrire a[$1] qui s'évalue à TRUE si cet indice (port) existe dans le premier fichier.

---

Elle est incorrecte car elle est toujours vraie alors que a[$1] n'est pas toujours vraie. Tu le dis toi-même

Citation:

---

Envoyé par ripat

Sans elle, la deuxième instruction serait inutilement exécutée pour toutes les lignes du premier fichier.

---

D'accord.

Citation:

---

Envoyé par ripat

Quant à la rapidité d'exécution, tout dépend du contexte et de la taille des fichiers.

---

On ne peut parler que de la vitesse algorithmique....
Si tu commences à comparer le nombre de lignes, les microprocesseurs, etc, on n'est pas arrivé.

Code:

---

Also, whenever you're doing grep | grep | awk | kitchen | sink, you should just replace it all with one simple awk command.

---

awk sait tout faire mais il le fait mal. grep ne sait que filtrer mais il le fait bien.
Cf les temps que j'ai indiqué plus haut.


Toutes ces choses étant dites, la méthode awk donnée ici est mauvaise car elle présuppose qu'il n'y a qu'une adresse par port. Ce qui paraît douteux. (L'inverse serait tout aussi douteux)

Non seulement il ne marche pas car l'association est douteuse, mais en plus, il y a un espace entre le ";" et le port qui fait que les deux ne correspondront jamais. Il faut proposer une solution du style:

Code:

---

1 2	$ awk -F';' '(FNR==NR){plouf=" "$1;a[plouf]++} (FNR>NR){if ($2 in a) print $1}' filtre.txt initial.txt 00.1F.FF.5H.66

---

ou

Code:

---

1 2	$ awk -F'; ' '(FNR==NR){a[$1]++} (FNR>NR){if ($2 in a) print $1}' filtre.txt initial.txt 00.1F.FF.5H.66

---

Citation:

---

Envoyé par Flodelarab

Code:

---

1 2	$ awk -F'; ' '(FNR==NR){a[$1]++} (FNR>NR){if ($2 in a) print $1}' filtre.txt initial.txt 00.1F.FF.5H.66

---

---

Tu pourrais te passer de la condition de la deuxième instruction en utilisant l'instruction next dans la lecture du premier fichier. De plus cette condition n'est pas correcte. FNR>NR s'évaluera toujours à FALSE. FNR ne sera jamais supérieur à NR dans la lecture de fichiers multiples. Impossible.

La construction:awk 'FNR==NR{instruction pour fichier1; next} {instruction pour fichier2}' fichier1 fichier2 est un grand classique de lecture de fichier multiple.

Un peu de lecture:
http://www.unix.com/shell-programmin...oduce-3rd.html
http://www.staff.science.uu.nl/~oost...k/nawk_77.html
http://www.catonmat.net/blog/ten-awk...k_be_idiomatic

Oui FNR<NR et pas FNR>NR

T'as trouvé la bonne faute pour une méthode qui de toute façon ne marche pas. (cf plus haut plusieurs adresses pour un seul port) :lol:

Citation:

---

Envoyé par Flodelarab

Oui FNR<NR et pas FNR>NR

T'as trouvé la bonne faute pour une méthode qui de toute façon ne marche pas. (cf plus haut plusieurs adresses pour un seul port) :lol:

---

Si, si, c'est possible en aménageant un peu le code awk:

Code:

---

awk -F' ; ' 'FNR==NR{a[$2]=a[$2] "\n" $1;next}a[$1]{printf a[$1]}' mac port

---

Alors plusieurs remarques:

-Les méthodes avec le sed ne fonctionnent pas correctement, car l'expression régulière n'est pas tout à fait correcte, elle confont au niveau des ports la valeur 1 avec 10 à 19, 2 avec 20 à 29, etc...

-Dans toutes les méthodes awk proposées, chez moi il n'y a que celle de N_BaH qui fonctionne où d'ailleurs on peut se passer de FNR==NR puisque le 2éme champs étant inexistant dans le fichier port, on ne risque pas d'écrasement de valeur et c'est d'ailleurs pour cela qu'elle fonctionne aussi avec l'erreur FNR=NR

Pas testé les méthodes avec join, car potentiellement trop lente.

Sinon, après correction de la regex coté sed (ou grep), la méthode awk à l'air plus rapide d'environ 25%... (mais bon, chez moi, je suis en cygwin, donc difficile à bien juger)