Bonjour,
J'ai une quantité conséquente de fichiers CSV (et divers autres) encodés
en iso-8859-1 qui viennent d'une parc d'ordinateur qui est maintenant
hors d'usage.
Les ordinateurs actuels sont en utf-8. Je souhaite passer une moulinette
iso-8859-1 -> utf-8 en masse à tous ces fichiers.
Laquelle me conseillez-vous?
J'ai un peu cherché avec:
http://www.google.fr/search?q=iso-8859-1+to+utf-8
mais n'ai rien trouvé.
--
Serveurs infogérés:
http://www.infogerance.us/infogerance/packs-serveurs-infogeres
Le 18-10-2008, ? propos de Re: convertir en utf-8 en masse, Nicolas George ?crivait dans fr.comp.os.unix :
JKB wrote in message :
J'aimerais savoir en quoi c'est une ânerie
1. ls est très souvent aliasé, ce qui peut rendre inutilisable sa sortie pour un script.
ls n'est pas fait pour les chiens. ls -1 non plus. Lorsque j'écris
ls -1 n'est pas nécessaire dans les script, il est implicite.
Non, -1 n'est implicite que si la stdout de ls n'est pas un terminal, ce qui n'a rien a voir avec script ou pas script.
un script, j'ai toujours un unalias -a au début. Pourquoi ? Parce
mauvaise habitude, sutout en korn shell si tu utilise integer, autoload, etc.
et inutil.
-- Stéphane
JKB
Le 20-10-2008, ? propos de Re: convertir en utf-8 en masse, Stephane CHAZELAS ?crivait dans fr.comp.os.unix :
2008-10-18, 09:54(+00), JKB: [...]
Non, le monsieur t'a demandé la différence entre 'for i in *' et 'for i in $(ls -1)' indépendamment des problèmes d'espace. Je t'aide, il y a une différence d'expansion et de longueur de ligne (enfin pour un shell correctement fichu). J'ai des tas d'exemples où la première forme explose et pas la seconde.
[...]
Oui, des exemples STP.
Les tuiles de cartographie de la France entière à je ne sais plus quelle échelle (plusieurs centaines de milliers de fichiers de 4Ko par répertoire), le tout sous Solaris 9 (je ne sais plus quel shell, mais probablement un dérivé du sh).
for i in * -> dépassement de la longueur maximale de ligne for i in `ls` -> OK parce que le truc traite ça avec un pipe. for i in `ls 1*` -> dépassement de la longueur maximale de ligne
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 20-10-2008, ? propos de
Re: convertir en utf-8 en masse,
Stephane CHAZELAS ?crivait dans fr.comp.os.unix :
2008-10-18, 09:54(+00), JKB:
[...]
Non, le monsieur t'a demandé la différence entre 'for i in *' et
'for i in $(ls -1)' indépendamment des problèmes d'espace. Je t'aide,
il y a une différence d'expansion et de longueur de ligne (enfin
pour un shell correctement fichu). J'ai des tas d'exemples où la
première forme explose et pas la seconde.
[...]
Oui, des exemples STP.
Les tuiles de cartographie de la France entière à je ne sais plus
quelle échelle (plusieurs centaines de milliers de fichiers de 4Ko
par répertoire), le tout sous Solaris 9 (je ne sais plus quel shell,
mais probablement un dérivé du sh).
for i in * -> dépassement de la longueur maximale de ligne
for i in `ls` -> OK parce que le truc traite ça avec un pipe.
for i in `ls 1*` -> dépassement de la longueur maximale de ligne
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 20-10-2008, ? propos de Re: convertir en utf-8 en masse, Stephane CHAZELAS ?crivait dans fr.comp.os.unix :
2008-10-18, 09:54(+00), JKB: [...]
Non, le monsieur t'a demandé la différence entre 'for i in *' et 'for i in $(ls -1)' indépendamment des problèmes d'espace. Je t'aide, il y a une différence d'expansion et de longueur de ligne (enfin pour un shell correctement fichu). J'ai des tas d'exemples où la première forme explose et pas la seconde.
[...]
Oui, des exemples STP.
Les tuiles de cartographie de la France entière à je ne sais plus quelle échelle (plusieurs centaines de milliers de fichiers de 4Ko par répertoire), le tout sous Solaris 9 (je ne sais plus quel shell, mais probablement un dérivé du sh).
for i in * -> dépassement de la longueur maximale de ligne for i in `ls` -> OK parce que le truc traite ça avec un pipe. for i in `ls 1*` -> dépassement de la longueur maximale de ligne
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Stephane CHAZELAS
2008-10-20, 11:00(+00), JKB:
Le 20-10-2008, ? propos de Re: convertir en utf-8 en masse, Stephane CHAZELAS ?crivait dans fr.comp.os.unix :
2008-10-18, 09:54(+00), JKB: [...]
Non, le monsieur t'a demandé la différence entre 'for i in *' et 'for i in $(ls -1)' indépendamment des problèmes d'espace. Je t'aide, il y a une différence d'expansion et de longueur de ligne (enfin pour un shell correctement fichu). J'ai des tas d'exemples où la première forme explose et pas la seconde.
[...]
Oui, des exemples STP.
Les tuiles de cartographie de la France entière à je ne sais plus quelle échelle (plusieurs centaines de milliers de fichiers de 4Ko par répertoire), le tout sous Solaris 9 (je ne sais plus quel shell, mais probablement un dérivé du sh).
for i in * -> dépassement de la longueur maximale de ligne
Quelle longueur maximale de ligne? Je ne vois pas pourquoi il y aurait une limitation ici. Il n'y en a certainement pas as far as POSIX ou le Bourne shell sont concernés.
for i in `ls` -> OK parce que le truc traite ça avec un pipe. for i in `ls 1*` -> dépassement de la longueur maximale de ligne
[...]
Là, c'est plus probablement la limite de la taille des arguments (et environment) à l'appel system execve(2) qui echoue alors avec errno = E2BIG et le message d'erreur correspondant "Argument list too long".
A ma connaissance, ce genre d'erreur n'intervient qu'a l'execution d'une commande. Note que certains systemes come hurd ou les versions recentes de Linux n'ont pas/plus cette limite.
Dans for i in *, la limite est la memoire disponible.
-- Stéphane
2008-10-20, 11:00(+00), JKB:
Le 20-10-2008, ? propos de
Re: convertir en utf-8 en masse,
Stephane CHAZELAS ?crivait dans fr.comp.os.unix :
2008-10-18, 09:54(+00), JKB:
[...]
Non, le monsieur t'a demandé la différence entre 'for i in *' et
'for i in $(ls -1)' indépendamment des problèmes d'espace. Je t'aide,
il y a une différence d'expansion et de longueur de ligne (enfin
pour un shell correctement fichu). J'ai des tas d'exemples où la
première forme explose et pas la seconde.
[...]
Oui, des exemples STP.
Les tuiles de cartographie de la France entière à je ne sais plus
quelle échelle (plusieurs centaines de milliers de fichiers de 4Ko
par répertoire), le tout sous Solaris 9 (je ne sais plus quel shell,
mais probablement un dérivé du sh).
for i in * -> dépassement de la longueur maximale de ligne
Quelle longueur maximale de ligne? Je ne vois pas pourquoi il y
aurait une limitation ici. Il n'y en a certainement pas as far
as POSIX ou le Bourne shell sont concernés.
for i in `ls` -> OK parce que le truc traite ça avec un pipe.
for i in `ls 1*` -> dépassement de la longueur maximale de ligne
[...]
Là, c'est plus probablement la limite de la taille des arguments
(et environment) à l'appel system execve(2) qui echoue alors avec
errno = E2BIG et le message d'erreur correspondant "Argument
list too long".
A ma connaissance, ce genre d'erreur n'intervient qu'a
l'execution d'une commande. Note que certains systemes come hurd
ou les versions recentes de Linux n'ont pas/plus cette limite.
Dans for i in *, la limite est la memoire disponible.
Le 20-10-2008, ? propos de Re: convertir en utf-8 en masse, Stephane CHAZELAS ?crivait dans fr.comp.os.unix :
2008-10-18, 09:54(+00), JKB: [...]
Non, le monsieur t'a demandé la différence entre 'for i in *' et 'for i in $(ls -1)' indépendamment des problèmes d'espace. Je t'aide, il y a une différence d'expansion et de longueur de ligne (enfin pour un shell correctement fichu). J'ai des tas d'exemples où la première forme explose et pas la seconde.
[...]
Oui, des exemples STP.
Les tuiles de cartographie de la France entière à je ne sais plus quelle échelle (plusieurs centaines de milliers de fichiers de 4Ko par répertoire), le tout sous Solaris 9 (je ne sais plus quel shell, mais probablement un dérivé du sh).
for i in * -> dépassement de la longueur maximale de ligne
Quelle longueur maximale de ligne? Je ne vois pas pourquoi il y aurait une limitation ici. Il n'y en a certainement pas as far as POSIX ou le Bourne shell sont concernés.
for i in `ls` -> OK parce que le truc traite ça avec un pipe. for i in `ls 1*` -> dépassement de la longueur maximale de ligne
[...]
Là, c'est plus probablement la limite de la taille des arguments (et environment) à l'appel system execve(2) qui echoue alors avec errno = E2BIG et le message d'erreur correspondant "Argument list too long".
A ma connaissance, ce genre d'erreur n'intervient qu'a l'execution d'une commande. Note que certains systemes come hurd ou les versions recentes de Linux n'ont pas/plus cette limite.
Dans for i in *, la limite est la memoire disponible.
-- Stéphane
Nicolas George
Stephane CHAZELAS wrote in message :
Pas dans un script, heureusement! Les shells qui interpretent les scripts ne lisent pas les fichiers de configuration interactive.
Bien sûr, mais JKB n'a pas dit si la ligne qu'il indiquait était à mettre dans un script ou à taper directement au prompt.
Par quand sa stdout est un pipe.
Ce n'est pas garanti.
Oui, c'est le principal probleme.
Dans un script en effet. Directement à l'invite, je dirais que le problème des alias (et en particulier -F) est aussi grave.
Stephane CHAZELAS wrote in message
<slrngfoo8g.69p.stephane.chazelas@spam.is.invalid>:
Pas dans un script, heureusement! Les shells qui interpretent les
scripts ne lisent pas les fichiers de configuration interactive.
Bien sûr, mais JKB n'a pas dit si la ligne qu'il indiquait était à mettre
dans un script ou à taper directement au prompt.
Par quand sa stdout est un pipe.
Ce n'est pas garanti.
Oui, c'est le principal probleme.
Dans un script en effet. Directement à l'invite, je dirais que le problème
des alias (et en particulier -F) est aussi grave.
Si on sort du POSIX, c'est probablement /autant guaranti/ que le support de l'option -1.
-- Stéphane
Stephane CHAZELAS
2008-10-20, 12:45(+00), Stephane CHAZELAS:
2008-10-20, 12:07(+00), Nicolas George: [...]
Par quand sa stdout est un pipe.
Ce n'est pas garanti.
C'est guaranti par POSIX.
Si on sort du POSIX, c'est probablement /autant guaranti/ que le support de l'option -1.
D'ailleurs, SUSv3 dit:
SUSv3> The -1 (one) option was historically found in BSD and SUSv3> BSD-derived implementations only. It is required in this SUSv3> volume of IEEE Std 1003.1-2001 so that conforming SUSv3> applications might ensure that output is one entry per SUSv3> line, even if the output is to a terminal.
-- Stéphane
2008-10-20, 12:45(+00), Stephane CHAZELAS:
2008-10-20, 12:07(+00), Nicolas George:
[...]
Par quand sa stdout est un pipe.
Ce n'est pas garanti.
C'est guaranti par POSIX.
Si on sort du POSIX, c'est probablement /autant guaranti/ que le
support de l'option -1.
D'ailleurs, SUSv3 dit:
SUSv3> The -1 (one) option was historically found in BSD and
SUSv3> BSD-derived implementations only. It is required in this
SUSv3> volume of IEEE Std 1003.1-2001 so that conforming
SUSv3> applications might ensure that output is one entry per
SUSv3> line, even if the output is to a terminal.
Si on sort du POSIX, c'est probablement /autant guaranti/ que le support de l'option -1.
D'ailleurs, SUSv3 dit:
SUSv3> The -1 (one) option was historically found in BSD and SUSv3> BSD-derived implementations only. It is required in this SUSv3> volume of IEEE Std 1003.1-2001 so that conforming SUSv3> applications might ensure that output is one entry per SUSv3> line, even if the output is to a terminal.
-- Stéphane
Hugues
Ce cher JKB a dit :
Sauf que tu n'as pas répondu à ma question. Il y a une différence fondamentale entre for i in $(ls) [ou for i in $(ls -1)] et for i in *. La deuxième forme risque de merdoyer bien plus vite sur certains Unix,
C'est plus une question de shell que d'UNIX, non ?
Celle utilisant 'ls' est, AMHA, une ânerie, car ls n'est pas prévu pour être utilisé dans des scripts, mais pour formater de façon "lisible par un utilisateur" un listing de dossier/fichiers. Vous aurez de drôles de surprises avec les fichiers contenant des caractères un peu délicats (genre, des ", des ', des , et j'en passe..)
Tant qu'à faire, le mieux reste de passer par 'find'. Mais pas 'ls'.
-- Hugues
Ce cher JKB <knatschke@koenigsberg.fr> a dit :
Sauf que tu n'as pas répondu à ma question. Il y a une différence
fondamentale entre for i in $(ls) [ou for i in $(ls -1)] et for i in *.
La deuxième forme risque de merdoyer bien plus vite sur certains Unix,
C'est plus une question de shell que d'UNIX, non ?
Celle utilisant 'ls' est, AMHA, une ânerie, car ls n'est pas prévu
pour être utilisé dans des scripts, mais pour formater de façon
"lisible par un utilisateur" un listing de dossier/fichiers. Vous
aurez de drôles de surprises avec les fichiers contenant des
caractères un peu délicats (genre, des ", des ', des , et j'en passe..)
Tant qu'à faire, le mieux reste de passer par 'find'. Mais pas 'ls'.
Sauf que tu n'as pas répondu à ma question. Il y a une différence fondamentale entre for i in $(ls) [ou for i in $(ls -1)] et for i in *. La deuxième forme risque de merdoyer bien plus vite sur certains Unix,
C'est plus une question de shell que d'UNIX, non ?
Celle utilisant 'ls' est, AMHA, une ânerie, car ls n'est pas prévu pour être utilisé dans des scripts, mais pour formater de façon "lisible par un utilisateur" un listing de dossier/fichiers. Vous aurez de drôles de surprises avec les fichiers contenant des caractères un peu délicats (genre, des ", des ', des , et j'en passe..)
Tant qu'à faire, le mieux reste de passer par 'find'. Mais pas 'ls'.
-- Hugues
Hugues
Ce cher Stephane CHAZELAS a dit :
Là, c'est plus probablement la limite de la taille des arguments (et environment) à l'appel system execve(2) qui echoue alors avec errno = E2BIG et le message d'erreur correspondant "Argument list too long".
A ma connaissance, ce genre d'erreur n'intervient qu'a l'execution d'une commande. Note que certains systemes come hurd ou les versions recentes de Linux n'ont pas/plus cette limite.
Dans for i in *, la limite est la memoire disponible.
Tout dépend du shell. Sur zsh par exemple, il faut passer par zargs, ce qui est clairement moins pratique. Mais '*' ou '$(ls)', ça revient au même. Par contre, en passant par un pipe, seul ls est utilisable, ou find. Car '*' est interprété avant l'exécution de la commande.
En bref, je reste persuadé que '*' est préférable à '$(ls)' dans l'utilisation d'un shell de tous les jours, mais qu'il faut lui préférer '$(find)' pour des plus gros travaux, notamment dans un shellscript par exemple.
-- Hugues
Ce cher Stephane CHAZELAS <stephane_chazelas@yahoo.fr> a dit :
Là, c'est plus probablement la limite de la taille des arguments
(et environment) à l'appel system execve(2) qui echoue alors avec
errno = E2BIG et le message d'erreur correspondant "Argument
list too long".
A ma connaissance, ce genre d'erreur n'intervient qu'a
l'execution d'une commande. Note que certains systemes come hurd
ou les versions recentes de Linux n'ont pas/plus cette limite.
Dans for i in *, la limite est la memoire disponible.
Tout dépend du shell. Sur zsh par exemple, il faut passer par zargs,
ce qui est clairement moins pratique. Mais '*' ou '$(ls)', ça revient
au même. Par contre, en passant par un pipe, seul ls est utilisable,
ou find. Car '*' est interprété avant l'exécution de la commande.
En bref, je reste persuadé que '*' est préférable à '$(ls)' dans
l'utilisation d'un shell de tous les jours, mais qu'il faut lui
préférer '$(find)' pour des plus gros travaux, notamment dans un
shellscript par exemple.
Là, c'est plus probablement la limite de la taille des arguments (et environment) à l'appel system execve(2) qui echoue alors avec errno = E2BIG et le message d'erreur correspondant "Argument list too long".
A ma connaissance, ce genre d'erreur n'intervient qu'a l'execution d'une commande. Note que certains systemes come hurd ou les versions recentes de Linux n'ont pas/plus cette limite.
Dans for i in *, la limite est la memoire disponible.
Tout dépend du shell. Sur zsh par exemple, il faut passer par zargs, ce qui est clairement moins pratique. Mais '*' ou '$(ls)', ça revient au même. Par contre, en passant par un pipe, seul ls est utilisable, ou find. Car '*' est interprété avant l'exécution de la commande.
En bref, je reste persuadé que '*' est préférable à '$(ls)' dans l'utilisation d'un shell de tous les jours, mais qu'il faut lui préférer '$(find)' pour des plus gros travaux, notamment dans un shellscript par exemple.
-- Hugues
Hugues
Ce cher Paul Gaborit a dit :
À (at) Fri, 17 Oct 2008 21:09:40 +0300, "Rakotomandimby (R12y) Mihamina" écrivait (wrote):
Bonjour, J'ai une quantité conséquente de fichiers CSV (et divers autres) encodés en iso-8859-1 qui viennent d'une parc d'ordinateur qui est maintenant hors d'usage. Les ordinateurs actuels sont en utf-8. Je souhaite passer une moulinette iso-8859-1 -> utf-8 en masse à tous ces fichiers. Laquelle me conseillez-vous? J'ai un peu cherché avec: http://www.google.fr/search?q=iso-8859-1+to+utf-8 mais n'ai rien trouvé.
recode latin1..utf8 *
Je plussoie. Heureusement que j'ai lu tout le thread avant de répondre ;)
Pour synthétiser avec les réponses précédentes :
find . -type f -exec recode latin1..utf8 '{}' ';'
Pas de '*', pas de 'ls'. Que demander de mieux ?
-- Hugues
Ce cher Paul Gaborit <Paul.Gaborit@invalid.invalid> a dit :
À (at) Fri, 17 Oct 2008 21:09:40 +0300,
"Rakotomandimby (R12y) Mihamina" <mihamina@infogerance.us> écrivait (wrote):
Bonjour,
J'ai une quantité conséquente de fichiers CSV (et divers autres)
encodés en iso-8859-1 qui viennent d'une parc d'ordinateur qui est
maintenant hors d'usage.
Les ordinateurs actuels sont en utf-8. Je souhaite passer une
moulinette iso-8859-1 -> utf-8 en masse à tous ces fichiers.
Laquelle me conseillez-vous?
J'ai un peu cherché avec:
http://www.google.fr/search?q=iso-8859-1+to+utf-8
mais n'ai rien trouvé.
recode latin1..utf8 *
Je plussoie.
Heureusement que j'ai lu tout le thread avant de répondre ;)
À (at) Fri, 17 Oct 2008 21:09:40 +0300, "Rakotomandimby (R12y) Mihamina" écrivait (wrote):
Bonjour, J'ai une quantité conséquente de fichiers CSV (et divers autres) encodés en iso-8859-1 qui viennent d'une parc d'ordinateur qui est maintenant hors d'usage. Les ordinateurs actuels sont en utf-8. Je souhaite passer une moulinette iso-8859-1 -> utf-8 en masse à tous ces fichiers. Laquelle me conseillez-vous? J'ai un peu cherché avec: http://www.google.fr/search?q=iso-8859-1+to+utf-8 mais n'ai rien trouvé.
recode latin1..utf8 *
Je plussoie. Heureusement que j'ai lu tout le thread avant de répondre ;)
Pour synthétiser avec les réponses précédentes :
find . -type f -exec recode latin1..utf8 '{}' ';'
Pas de '*', pas de 'ls'. Que demander de mieux ?
-- Hugues
Hugues
Ce cher Stephane CHAZELAS a dit :
Là, c'est plus probablement la limite de la taille des arguments (et environment) à l'appel system execve(2) qui echoue alors avec errno = E2BIG et le message d'erreur correspondant "Argument list too long".
A ma connaissance, ce genre d'erreur n'intervient qu'a l'execution d'une commande. Note que certains systemes come hurd ou les versions recentes de Linux n'ont pas/plus cette limite.
Dans for i in *, la limite est la memoire disponible.
Tout dépend du shell. Sur zsh par exemple, il faut passer par zargs, ce qui est clairement moins pratique. Mais '*' ou '$(ls)', ça revient au même. Par contre, en passant par un pipe, seul ls est utilisable, ou find. Car '*' est interprété avant l'exécution de la commande.
En bref, je reste persuadé que '*' est préférable à '$(ls)' dans l'utilisation d'un shell de tous les jours, mais qu'il faut lui préférer 'find -exec' pour des plus gros travaux, notamment dans un shellscript par exemple.
-- Hugues
Ce cher Stephane CHAZELAS <stephane_chazelas@yahoo.fr> a dit :
Là, c'est plus probablement la limite de la taille des arguments
(et environment) à l'appel system execve(2) qui echoue alors avec
errno = E2BIG et le message d'erreur correspondant "Argument
list too long".
A ma connaissance, ce genre d'erreur n'intervient qu'a
l'execution d'une commande. Note que certains systemes come hurd
ou les versions recentes de Linux n'ont pas/plus cette limite.
Dans for i in *, la limite est la memoire disponible.
Tout dépend du shell. Sur zsh par exemple, il faut passer par zargs,
ce qui est clairement moins pratique. Mais '*' ou '$(ls)', ça revient
au même. Par contre, en passant par un pipe, seul ls est utilisable,
ou find. Car '*' est interprété avant l'exécution de la commande.
En bref, je reste persuadé que '*' est préférable à '$(ls)' dans
l'utilisation d'un shell de tous les jours, mais qu'il faut lui
préférer 'find -exec' pour des plus gros travaux, notamment dans un
shellscript par exemple.
Là, c'est plus probablement la limite de la taille des arguments (et environment) à l'appel system execve(2) qui echoue alors avec errno = E2BIG et le message d'erreur correspondant "Argument list too long".
A ma connaissance, ce genre d'erreur n'intervient qu'a l'execution d'une commande. Note que certains systemes come hurd ou les versions recentes de Linux n'ont pas/plus cette limite.
Dans for i in *, la limite est la memoire disponible.
Tout dépend du shell. Sur zsh par exemple, il faut passer par zargs, ce qui est clairement moins pratique. Mais '*' ou '$(ls)', ça revient au même. Par contre, en passant par un pipe, seul ls est utilisable, ou find. Car '*' est interprété avant l'exécution de la commande.
En bref, je reste persuadé que '*' est préférable à '$(ls)' dans l'utilisation d'un shell de tous les jours, mais qu'il faut lui préférer 'find -exec' pour des plus gros travaux, notamment dans un shellscript par exemple.
