j'ai un fichier de données, avec une première ligne d'en-tête. J'aimerais
trier le fichier, sauf la première ligne. Et je ne trouve pas de façon
élégante de le faire.
Je peux supprimer la première ligne, mais je ne trouve pas de façon
élégante de la remettre ensuite... Je sais faire un script qui sauvera
dans une variable la première ligne, fera le tri, remettra la ligne,
mais bon, c'est un peu lourd...
sed 1d toto.csv | sort > toto-sorted.csv
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
Le 22-06-2012, Marc Boyer a écrit : > Bonjour, > > j'ai un fichier de données, avec une première ligne d'en-tête. J'aimerais > trier le fichier, sauf la première ligne. Et je ne trouve pas de façon > élégante de le faire. > > Je peux supprimer la première ligne, mais je ne trouve pas de façon > élégante de la remettre ensuite... Je sais faire un script qui sauvera > dans une variable la première ligne, fera le tri, remettra la ligne, > mais bon, c'est un peu lourd...
Fallait juste réfléchir: { head -1 toto.csv && sed 1d toto.csv | sort }
[...]
Ou:
{ head -n 1 && sort; } < toto.csv
Ne marche sur les systemes POSIX que si "toto.csv" est un fichier regulier (seekable).
Note que "sed 1d" peut aussi s'ecrire "tail -n +2".
-- Stephane
2012-06-22 11:27:20 +0000, Marc Boyer:
Le 22-06-2012, Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> a écrit :
> Bonjour,
>
> j'ai un fichier de données, avec une première ligne d'en-tête. J'aimerais
> trier le fichier, sauf la première ligne. Et je ne trouve pas de façon
> élégante de le faire.
>
> Je peux supprimer la première ligne, mais je ne trouve pas de façon
> élégante de la remettre ensuite... Je sais faire un script qui sauvera
> dans une variable la première ligne, fera le tri, remettra la ligne,
> mais bon, c'est un peu lourd...
Fallait juste réfléchir:
{ head -1 toto.csv && sed 1d toto.csv | sort }
[...]
Ou:
{ head -n 1 && sort; } < toto.csv
Ne marche sur les systemes POSIX que si "toto.csv" est un
fichier regulier (seekable).
Note que "sed 1d" peut aussi s'ecrire "tail -n +2".
Le 22-06-2012, Marc Boyer a écrit : > Bonjour, > > j'ai un fichier de données, avec une première ligne d'en-tête. J'aimerais > trier le fichier, sauf la première ligne. Et je ne trouve pas de façon > élégante de le faire. > > Je peux supprimer la première ligne, mais je ne trouve pas de façon > élégante de la remettre ensuite... Je sais faire un script qui sauvera > dans une variable la première ligne, fera le tri, remettra la ligne, > mais bon, c'est un peu lourd...
Fallait juste réfléchir: { head -1 toto.csv && sed 1d toto.csv | sort }
[...]
Ou:
{ head -n 1 && sort; } < toto.csv
Ne marche sur les systemes POSIX que si "toto.csv" est un fichier regulier (seekable).
Note que "sed 1d" peut aussi s'ecrire "tail -n +2".
-- Stephane
Nicolas George
Marc Boyer , dans le message <js1vlu$298$, a écrit :
Mais si on a des champs du type "Data1", "Data 2, avec des bizzareries dedans, des quotes "" en plus", Data3 Ca devient plus coton... Formellement parlant, je soupsonne qu'on soit pas dans la même classe de langages (mais c'est loin pour moi...)
Je soupçonne que Jean-Marc voulait évoquer un utilitaire « csvawk » qui fonctionnerait comme awk, avec le même langage, la même logique, mais qui au lieu de lire un fichier texte ligne par ligne, lirait un fichier CSV ligne de tableau par ligne de tableau, et stockerait dans $1, $2, etc., les différentes colonnes, avec l'échappement décodé.
Ça n'aurait rien de difficile en principe.
En pratique, ça me semble un peu trop ad-hoc.
Marc Boyer , dans le message <js1vlu$298$1@news.cict.fr>, a écrit :
Mais si on a des champs du type
"Data1", "Data 2, avec des
bizzareries dedans, des quotes "" en plus", Data3
Ca devient plus coton... Formellement parlant, je soupsonne qu'on
soit pas dans la même classe de langages (mais c'est loin pour moi...)
Je soupçonne que Jean-Marc voulait évoquer un utilitaire « csvawk » qui
fonctionnerait comme awk, avec le même langage, la même logique, mais qui au
lieu de lire un fichier texte ligne par ligne, lirait un fichier CSV ligne
de tableau par ligne de tableau, et stockerait dans $1, $2, etc., les
différentes colonnes, avec l'échappement décodé.
Marc Boyer , dans le message <js1vlu$298$, a écrit :
Mais si on a des champs du type "Data1", "Data 2, avec des bizzareries dedans, des quotes "" en plus", Data3 Ca devient plus coton... Formellement parlant, je soupsonne qu'on soit pas dans la même classe de langages (mais c'est loin pour moi...)
Je soupçonne que Jean-Marc voulait évoquer un utilitaire « csvawk » qui fonctionnerait comme awk, avec le même langage, la même logique, mais qui au lieu de lire un fichier texte ligne par ligne, lirait un fichier CSV ligne de tableau par ligne de tableau, et stockerait dans $1, $2, etc., les différentes colonnes, avec l'échappement décodé.
Ça n'aurait rien de difficile en principe.
En pratique, ça me semble un peu trop ad-hoc.
Jean-Marc Bourguet
Nicolas George <nicolas$ writes:
Marc Boyer , dans le message <js1vlu$298$, a écrit :
Mais si on a des champs du type "Data1", "Data 2, avec des bizzareries dedans, des quotes "" en plus", Data3 Ca devient plus coton... Formellement parlant, je soupsonne qu'on soit pas dans la même classe de langages (mais c'est loin pour moi...)
Je soupçonne que Jean-Marc voulait évoquer un utilitaire « csvawk » qui fonctionnerait comme awk, avec le même langage, la même logique, mais qui au lieu de lire un fichier texte ligne par ligne, lirait un fichier CSV ligne de tableau par ligne de tableau, et stockerait dans $1, $2, etc., les différentes colonnes, avec l'échappement décodé.
Ça n'aurait rien de difficile en principe.
En pratique, ça me semble un peu trop ad-hoc.
Je pensais plutot a awk --cvs, mais l'idée est bien celle-là.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Nicolas George <nicolas$george@salle-s.org> writes:
Marc Boyer , dans le message <js1vlu$298$1@news.cict.fr>, a écrit :
Mais si on a des champs du type
"Data1", "Data 2, avec des
bizzareries dedans, des quotes "" en plus", Data3
Ca devient plus coton... Formellement parlant, je soupsonne qu'on
soit pas dans la même classe de langages (mais c'est loin pour moi...)
Je soupçonne que Jean-Marc voulait évoquer un utilitaire « csvawk » qui
fonctionnerait comme awk, avec le même langage, la même logique, mais qui au
lieu de lire un fichier texte ligne par ligne, lirait un fichier CSV ligne
de tableau par ligne de tableau, et stockerait dans $1, $2, etc., les
différentes colonnes, avec l'échappement décodé.
Ça n'aurait rien de difficile en principe.
En pratique, ça me semble un peu trop ad-hoc.
Je pensais plutot a awk --cvs, mais l'idée est bien celle-là.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer , dans le message <js1vlu$298$, a écrit :
Mais si on a des champs du type "Data1", "Data 2, avec des bizzareries dedans, des quotes "" en plus", Data3 Ca devient plus coton... Formellement parlant, je soupsonne qu'on soit pas dans la même classe de langages (mais c'est loin pour moi...)
Je soupçonne que Jean-Marc voulait évoquer un utilitaire « csvawk » qui fonctionnerait comme awk, avec le même langage, la même logique, mais qui au lieu de lire un fichier texte ligne par ligne, lirait un fichier CSV ligne de tableau par ligne de tableau, et stockerait dans $1, $2, etc., les différentes colonnes, avec l'échappement décodé.
Ça n'aurait rien de difficile en principe.
En pratique, ça me semble un peu trop ad-hoc.
Je pensais plutot a awk --cvs, mais l'idée est bien celle-là.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
jca+news
Stephane Chazelas writes:
[...]
Ou:
{ head -n 1 && sort; } < toto.csv
Ne marche sur les systemes POSIX que si "toto.csv" est un fichier regulier (seekable).
et un UUOC de la plus belle eau :) Plus simplement
;-)
Et m... zut ! J'ai essayé de l'éviter sur la première forme (sans perl), sans succès (read -u prend un fd, ce qui alourdit les choses), et du coup j'ai copié-collé pour la version perl. Désolé !
Bonjour,
je ne vois pas pourquoi la forme suivante ne fonctionnerai pas !
(read -r; printf "%sn" "$REPLY"; sort) < fichier
que viens faire le read -u la dedans ?
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
* Emmanuel Florac<eflorac@imaginet.fr> in fr.comp.os.unix:
et un UUOC de la plus belle eau :) Plus simplement
;-)
Et m... zut ! J'ai essayé de l'éviter sur la première forme (sans perl),
sans succès (read -u prend un fd, ce qui alourdit les choses), et du
coup j'ai copié-collé pour la version perl. Désolé !
Bonjour,
je ne vois pas pourquoi la forme suivante ne fonctionnerai pas !
(read -r; printf "%sn" "$REPLY"; sort) < fichier
que viens faire le read -u la dedans ?
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
et un UUOC de la plus belle eau :) Plus simplement
;-)
Et m... zut ! J'ai essayé de l'éviter sur la première forme (sans perl), sans succès (read -u prend un fd, ce qui alourdit les choses), et du coup j'ai copié-collé pour la version perl. Désolé !
Bonjour,
je ne vois pas pourquoi la forme suivante ne fonctionnerai pas !
(read -r; printf "%sn" "$REPLY"; sort) < fichier
que viens faire le read -u la dedans ?
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Damien Wyart
* Cyrille Lefevre <cyrille.lefevre-news% in fr.comp.os.unix:
je ne vois pas pourquoi la forme suivante ne fonctionnerai pas !
(read -r; printf "%sn" "$REPLY"; sort) < fichier
En effet, merci pour cette suggestion. -- DW
* Cyrille Lefevre <cyrille.lefevre-news%nospam@laposte.net.invalid>
in fr.comp.os.unix:
je ne vois pas pourquoi la forme suivante ne fonctionnerai pas !
Je ne vois rien dans le standard qui garantisse que read ne va pas lire au delà de la première ligne, par exemple au niveau d'un buffer stdio.
Stephane Chazelas
2012-06-25 11:33:42 +0000, Nicolas George:
Stephane Chazelas , dans le message , a écrit : > (IFS= read -r firstline && printf "%sn" "$firstline" && sort) < fichier
Je ne vois rien dans le standard qui garantisse que read ne va pas lire au delà de la première ligne, par exemple au niveau d'un buffer stdio.
De meme que pour "sed" et "tail", le standard le guarantit si "fichier" est seekable. Il ne le guarantee peut-etre pas pour "read" pour les fichiers non-seekable, mais en pratique, tous les shells existant le guarantissent (en lisant un byte a la fois si le fichier n'est pas seekable est n'est pas un terminal).
-- Stephane
2012-06-25 11:33:42 +0000, Nicolas George:
Stephane Chazelas , dans le message
<20120625110200.GC11186@chaz.gmail.com>, a écrit :
> (IFS= read -r firstline && printf "%sn" "$firstline" && sort) < fichier
Je ne vois rien dans le standard qui garantisse que read ne va pas lire au
delà de la première ligne, par exemple au niveau d'un buffer stdio.
De meme que pour "sed" et "tail", le standard le guarantit si
"fichier" est seekable. Il ne le guarantee peut-etre pas pour
"read" pour les fichiers non-seekable, mais en pratique, tous
les shells existant le guarantissent (en lisant un byte a la
fois si le fichier n'est pas seekable est n'est pas un
terminal).
Stephane Chazelas , dans le message , a écrit : > (IFS= read -r firstline && printf "%sn" "$firstline" && sort) < fichier
Je ne vois rien dans le standard qui garantisse que read ne va pas lire au delà de la première ligne, par exemple au niveau d'un buffer stdio.
De meme que pour "sed" et "tail", le standard le guarantit si "fichier" est seekable. Il ne le guarantee peut-etre pas pour "read" pour les fichiers non-seekable, mais en pratique, tous les shells existant le guarantissent (en lisant un byte a la fois si le fichier n'est pas seekable est n'est pas un terminal).
-- Stephane
Nicolas George
Stephane Chazelas , dans le message , a écrit :
De meme que pour "sed" et "tail", le standard le guarantit si "fichier" est seekable.
[citation needed]
Stephane Chazelas , dans le message
<20120625125848.GD11186@chaz.gmail.com>, a écrit :
De meme que pour "sed" et "tail", le standard le guarantit si
"fichier" est seekable.
