comme je sais qu'il existe pleins de petits utilitaires en ligne
de commande méconnus, je me demandais s'il y en avait un qui
permettrait de voir des fichiers csv.
Souvent, on cat un .csv, et la largeur des champs des colonnes
fait que ça apparait un peu en vrac:
$ cat file.csv
Jour;nombre de hits;disponibilité;colonne D
Mercredi;8;N;Obiwan
;;;E
Jeudi;Non disponible;;;
et ce n'est pas super simple à lire
si on pouvait avoir:
$ supertool file.csv
Jour; nombre de hits; disponibilité; colonne D
Mercredi; 8; N; Obiwan
; ; ; E
Jeudi; Non disponible; ;
J'ai effectivement mal compris le cahier des charges et le fonctionnement de /column/ : j'ai cru que l'option -s définissait le séparateur en entrée ET en sortie.
Ah, ok pas de problème.
Donc /tr/ ne convient pas. Il faut effectivement disposer de l'option -o de /column/ ou employer la solution /sed/ que j'ai proposée auparavant.
Alors, pardon d'insister ;), mais la commande *complète* avec le "sed" je veux bien la voir car, encore une fois, dès l'instant où un des champs du csv contient lui-même le motif responsable de la séparation des colonnes (à savoir deux espaces je crois sur "column"), ben c'est la merde (que ce soit avec "sed", "tr" ou je ne sais quoi). ;)
Désolé pour le bruit.
Aucun souci.
-- François Lafont
On 13/10/2015 12:48, Dominique MICOLLET wrote:
J'ai effectivement mal compris le cahier des charges et le fonctionnement de
/column/ : j'ai cru que l'option -s définissait le séparateur en entrée ET
en sortie.
Ah, ok pas de problème.
Donc /tr/ ne convient pas. Il faut effectivement disposer de l'option -o de
/column/ ou employer la solution /sed/ que j'ai proposée auparavant.
Alors, pardon d'insister ;), mais la commande *complète* avec le "sed" je veux
bien la voir car, encore une fois, dès l'instant où un des champs du csv contient
lui-même le motif responsable de la séparation des colonnes (à savoir deux
espaces je crois sur "column"), ben c'est la merde (que ce soit avec "sed", "tr"
ou je ne sais quoi). ;)
J'ai effectivement mal compris le cahier des charges et le fonctionnement de /column/ : j'ai cru que l'option -s définissait le séparateur en entrée ET en sortie.
Ah, ok pas de problème.
Donc /tr/ ne convient pas. Il faut effectivement disposer de l'option -o de /column/ ou employer la solution /sed/ que j'ai proposée auparavant.
Alors, pardon d'insister ;), mais la commande *complète* avec le "sed" je veux bien la voir car, encore une fois, dès l'instant où un des champs du csv contient lui-même le motif responsable de la séparation des colonnes (à savoir deux espaces je crois sur "column"), ben c'est la merde (que ce soit avec "sed", "tr" ou je ne sais quoi). ;)
Désolé pour le bruit.
Aucun souci.
-- François Lafont
Dominique MICOLLET
Bonjour
Francois Lafont wrote:
Alors, pardon d'insister ;), mais la commande *complète* avec le "sed" je veux bien la voir
sed 's/;/t|/g' /tmp/test.csv | expand --tabs
me semble répondre au cahier des charges
Cordialement
Dominique
Bonjour
Francois Lafont wrote:
Alors, pardon d'insister ;), mais la commande *complète* avec le "sed" je
veux bien la voir
Le CSV, c'est un peu comme le Xml : au début on pense régler ça à la regexp, mais en fait, pour gérer tous les cas tordus, il faut en général un parser adapté.
Le CSV, c'est un peu comme le Xml : au début on pense régler ça
à la regexp, mais en fait, pour gérer tous les cas tordus, il faut
en général un parser adapté.
Le CSV, c'est un peu comme le Xml : au début on pense régler ça à la regexp, mais en fait, pour gérer tous les cas tordus, il faut en général un parser adapté.
I'm <tth> on freenode. Film at 11, take your popcorn.
Francois Lafont
On 13/10/2015 14:12, Dominique MICOLLET wrote:
sed 's/;/t|/g' /tmp/test.csv | expand --tabs
Chez moi, ça donne ça :
--------------------------------------------------- ~$ sed 's/;/t|/g' /tmp/test.csv | expand --tabs Jour |nombre de hits |disponibilité |colonne D Mercredi |8 |N |Obiwan | | |E Jeudi |Non disponible | | | ---------------------------------------------------
On voit donc un petit décalage au niveau de la « cellule » "disponibilité". C'est dû à la présence du « é » qui compte pour plusieurs « colonnes » pour la commande expand (dont j'ai eu un peu de mal à comprendre ce qu'elle faisait exactement). Si le fichier ne possède que des caractères ASCII, effectivement la commande ci-dessus fonctionne, mais sinon plus il y aura de caractères non ASCII plus les alignements en seront altérés.
Par ailleurs, faut quand même pas choisir la valeur de --tabs n'importe comment non plus, mais bon au pire on peut toujours prendre une valeur un peu trop grande.
Merci pour la réponse en tout cas. À+
-- François Lafont
On 13/10/2015 14:12, Dominique MICOLLET wrote:
sed 's/;/t|/g' /tmp/test.csv | expand --tabs
Chez moi, ça donne ça :
---------------------------------------------------
~$ sed 's/;/t|/g' /tmp/test.csv | expand --tabs
Jour |nombre de hits |disponibilité |colonne D
Mercredi |8 |N |Obiwan
| | |E
Jeudi |Non disponible | | |
---------------------------------------------------
On voit donc un petit décalage au niveau de la « cellule »
"disponibilité". C'est dû à la présence du « é » qui compte
pour plusieurs « colonnes » pour la commande expand (dont
j'ai eu un peu de mal à comprendre ce qu'elle faisait
exactement). Si le fichier ne possède que des caractères
ASCII, effectivement la commande ci-dessus fonctionne, mais
sinon plus il y aura de caractères non ASCII plus les
alignements en seront altérés.
Par ailleurs, faut quand même pas choisir la valeur de
--tabs n'importe comment non plus, mais bon au pire on peut
toujours prendre une valeur un peu trop grande.
--------------------------------------------------- ~$ sed 's/;/t|/g' /tmp/test.csv | expand --tabs Jour |nombre de hits |disponibilité |colonne D Mercredi |8 |N |Obiwan | | |E Jeudi |Non disponible | | | ---------------------------------------------------
On voit donc un petit décalage au niveau de la « cellule » "disponibilité". C'est dû à la présence du « é » qui compte pour plusieurs « colonnes » pour la commande expand (dont j'ai eu un peu de mal à comprendre ce qu'elle faisait exactement). Si le fichier ne possède que des caractères ASCII, effectivement la commande ci-dessus fonctionne, mais sinon plus il y aura de caractères non ASCII plus les alignements en seront altérés.
Par ailleurs, faut quand même pas choisir la valeur de --tabs n'importe comment non plus, mais bon au pire on peut toujours prendre une valeur un peu trop grande.
Merci pour la réponse en tout cas. À+
-- François Lafont
Dominique MICOLLET
Bonjour,
Tonton Th wrote:
Et si il y a un ';' dans un des champs du CSV, hein, on fait quoi ?
On se flagelle : il n'es t p as t r è s f ut é d'ut il is e r l e s épa rate ur de c ham p da ns u n c ham p.
C'est pour ça que le séparateur classique en unix est ":" (voir /etc/passwd).
Tonton Th serait un Troll ?
Cordialement
Dominique
Bonjour,
Tonton Th wrote:
Et si il y a un ';' dans un des champs du CSV, hein, on fait quoi ?
On se flagelle : il n'es t p as t r è s f ut é d'ut il is e r l e s épa
rate ur de c ham p da ns u n c ham p.
C'est pour ça que le séparateur classique en unix est ":" (voir
/etc/passwd).
Et si il y a un ';' dans un des champs du CSV, hein, on fait quoi ?
On se flagelle : il n'es t p as t r è s f ut é d'ut il is e r l e s épa rate ur de c ham p da ns u n c ham p.
C'est pour ça que le séparateur classique en unix est ":" (voir /etc/passwd).
Tonton Th serait un Troll ?
Cordialement
Dominique
Dominique MICOLLET
Bonjour,
Francois Lafont wrote:
On voit donc un petit décalage au niveau de la « cellule » "disponibilité". C'est dû à la présence du « é » qui compte pour plusieurs « colonnes » pour la commande expand
Oui : je crois - sans certitude - que c'est lié à l'UTF-8 qui doit coder le é sur deux octets qu'/expand/ compte donc comme deux caractères.
J'ai eu le même problème dans un programme C.
J'avoue ne pas savoir comment le résoudre ni en bash ni en C.
Cordialement
Dominique
Bonjour,
Francois Lafont wrote:
On voit donc un petit décalage au niveau de la « cellule »
"disponibilité". C'est dû à la présence du « é » qui compte
pour plusieurs « colonnes » pour la commande expand
Oui : je crois - sans certitude - que c'est lié à l'UTF-8 qui doit coder le
é sur deux octets qu'/expand/ compte donc comme deux caractères.
J'ai eu le même problème dans un programme C.
J'avoue ne pas savoir comment le résoudre ni en bash ni en C.
On voit donc un petit décalage au niveau de la « cellule » "disponibilité". C'est dû à la présence du « é » qui compte pour plusieurs « colonnes » pour la commande expand
Oui : je crois - sans certitude - que c'est lié à l'UTF-8 qui doit coder le é sur deux octets qu'/expand/ compte donc comme deux caractères.
J'ai eu le même problème dans un programme C.
J'avoue ne pas savoir comment le résoudre ni en bash ni en C.
Cordialement
Dominique
Tonton Th
On 2015-10-14, Dominique MICOLLET wrote:
Bonjour,
Tonton Th wrote:
Et si il y a un ';' dans un des champs du CSV, hein, on fait quoi ?
On se flagelle : il n'es t p as t r è s f ut é d'ut il is e r l e s épa rate ur de c ham p da ns u n c ham p.
C'est pour ça que le séparateur classique en unix est ":" (voir /etc/passwd).
Tonton Th serait un Troll ?
Je suis peut-être un troll, mais dans ma carrière je me suis déja trouvé plusieurs fois face aux problèmes de lecture de fichiers CSV, et je sais d'expérience que c'est loin d'être évident. Il y a une foultitude de cas particuliers, de petites déviations par rapport à la "norme" pour qu'un jour, et au mauvais moment, une solution "à la rache" explose en vol.
I'm <tth> on freenode. Film at 11, take your popcorn.
On 2015-10-14, Dominique MICOLLET <anonymous@invalid.fr> wrote:
Bonjour,
Tonton Th wrote:
Et si il y a un ';' dans un des champs du CSV, hein, on fait quoi ?
On se flagelle : il n'es t p as t r è s f ut é d'ut il is e r l e s épa
rate ur de c ham p da ns u n c ham p.
C'est pour ça que le séparateur classique en unix est ":" (voir
/etc/passwd).
Tonton Th serait un Troll ?
Je suis peut-être un troll, mais dans ma carrière je me suis
déja trouvé plusieurs fois face aux problèmes de lecture de
fichiers CSV, et je sais d'expérience que c'est loin d'être
évident. Il y a une foultitude de cas particuliers, de petites
déviations par rapport à la "norme" pour qu'un jour, et au
mauvais moment, une solution "à la rache" explose en vol.
Et si il y a un ';' dans un des champs du CSV, hein, on fait quoi ?
On se flagelle : il n'es t p as t r è s f ut é d'ut il is e r l e s épa rate ur de c ham p da ns u n c ham p.
C'est pour ça que le séparateur classique en unix est ":" (voir /etc/passwd).
Tonton Th serait un Troll ?
Je suis peut-être un troll, mais dans ma carrière je me suis déja trouvé plusieurs fois face aux problèmes de lecture de fichiers CSV, et je sais d'expérience que c'est loin d'être évident. Il y a une foultitude de cas particuliers, de petites déviations par rapport à la "norme" pour qu'un jour, et au mauvais moment, une solution "à la rache" explose en vol.
I'm <tth> on freenode. Film at 11, take your popcorn.
Olivier Miakinen
On 14/10/2015 07:36, Dominique MICOLLET wrote:
On voit donc un petit décalage au niveau de la « cellule » "disponibilité". C'est dû à la présence du « é » qui compte pour plusieurs « colonnes » pour la commande expand
Oui : je crois - sans certitude - que c'est lié à l'UTF-8 qui doit coder le é sur deux octets qu'/expand/ compte donc comme deux caractères.
Oui, en effet ça me semble logique.
J'ai eu le même problème dans un programme C.
J'avoue ne pas savoir comment le résoudre ni en bash ni en C.
Si tous les caractères font partie d'un seul jeu de caractères 8 bits, par exemple ISO-Latin1 ou CP1252, un contournement possible consiste à convertir le fichier d'UTF-8 dans ce jeu de caractères, puis utiliser expand, avant de reconvertir en UTF-8.
Mais il faudrait qu'existe une solution plus simple.
En tout cas d'autres se posent la question : http://superuser.com/questions/116907/how-to-recode-to-utf-8-conditionally
On 14/10/2015 07:36, Dominique MICOLLET wrote:
On voit donc un petit décalage au niveau de la « cellule »
"disponibilité". C'est dû à la présence du « é » qui compte
pour plusieurs « colonnes » pour la commande expand
Oui : je crois - sans certitude - que c'est lié à l'UTF-8 qui doit coder le
é sur deux octets qu'/expand/ compte donc comme deux caractères.
Oui, en effet ça me semble logique.
J'ai eu le même problème dans un programme C.
J'avoue ne pas savoir comment le résoudre ni en bash ni en C.
Si tous les caractères font partie d'un seul jeu de caractères 8 bits,
par exemple ISO-Latin1 ou CP1252, un contournement possible consiste à
convertir le fichier d'UTF-8 dans ce jeu de caractères, puis utiliser
expand, avant de reconvertir en UTF-8.
Mais il faudrait qu'existe une solution plus simple.
En tout cas d'autres se posent la question :
http://superuser.com/questions/116907/how-to-recode-to-utf-8-conditionally
On voit donc un petit décalage au niveau de la « cellule » "disponibilité". C'est dû à la présence du « é » qui compte pour plusieurs « colonnes » pour la commande expand
Oui : je crois - sans certitude - que c'est lié à l'UTF-8 qui doit coder le é sur deux octets qu'/expand/ compte donc comme deux caractères.
Oui, en effet ça me semble logique.
J'ai eu le même problème dans un programme C.
J'avoue ne pas savoir comment le résoudre ni en bash ni en C.
Si tous les caractères font partie d'un seul jeu de caractères 8 bits, par exemple ISO-Latin1 ou CP1252, un contournement possible consiste à convertir le fichier d'UTF-8 dans ce jeu de caractères, puis utiliser expand, avant de reconvertir en UTF-8.
Mais il faudrait qu'existe une solution plus simple.
En tout cas d'autres se posent la question : http://superuser.com/questions/116907/how-to-recode-to-utf-8-conditionally
Kevin Denis
Le 12-10-2015, Francois Lafont a écrit :
Il y a sûrement plus évolué mais perso j'utilise souvent la commande column pour faire ce genre de chose :
------------------------------------------------------ ~$ column -n -s ';' -t /tmp/test.csv Jour nombre de hits disponibilité colonne D Mercredi 8 N Obiwan E Jeudi Non disponible ------------------------------------------------------
Bon, tu verras dans la page man que column ne possède pas des tonnes d'options et que c'est peut-être un peu limité. Par exemple dans la sortie les colonnes sont délimitées par des espaces et je ne crois pas qu'on puisse changer cela (et mettre des '|' par exemple). En tout cas, je n'ai pas trouvé.
C'est largement suffisant pour avoir un résultat plus visuel. Merci, et pour les autres suggestions aussi :) -- Kevin
Le 12-10-2015, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
Il y a sûrement plus évolué mais perso j'utilise souvent
la commande column pour faire ce genre de chose :
------------------------------------------------------
~$ column -n -s ';' -t /tmp/test.csv
Jour nombre de hits disponibilité colonne D
Mercredi 8 N Obiwan
E
Jeudi Non disponible
------------------------------------------------------
Bon, tu verras dans la page man que column ne possède pas
des tonnes d'options et que c'est peut-être un peu limité.
Par exemple dans la sortie les colonnes sont délimitées par
des espaces et je ne crois pas qu'on puisse changer cela
(et mettre des '|' par exemple). En tout cas, je n'ai pas
trouvé.
C'est largement suffisant pour avoir un résultat plus visuel.
Merci, et pour les autres suggestions aussi :)
--
Kevin
Il y a sûrement plus évolué mais perso j'utilise souvent la commande column pour faire ce genre de chose :
------------------------------------------------------ ~$ column -n -s ';' -t /tmp/test.csv Jour nombre de hits disponibilité colonne D Mercredi 8 N Obiwan E Jeudi Non disponible ------------------------------------------------------
Bon, tu verras dans la page man que column ne possède pas des tonnes d'options et que c'est peut-être un peu limité. Par exemple dans la sortie les colonnes sont délimitées par des espaces et je ne crois pas qu'on puisse changer cela (et mettre des '|' par exemple). En tout cas, je n'ai pas trouvé.
C'est largement suffisant pour avoir un résultat plus visuel. Merci, et pour les autres suggestions aussi :) -- Kevin
