convertir en utf-8 en masse

2008-10-20, 15:19(+02), 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..)

[...]

Non, ni ', ni ", ni . Mais *, ?, [, SPC, TAB et NL en
l'occurrence (en supposant IFS non modifié). ', " et
deviennent un probleme avec xargs, ou si on utilise "eval" (mais
alors, il y en aura toute une floppee d'autres).

A part ca, je suis plutot d'accord. A part peut-etre sur
"ls n'est pas prevu pour etre utilisé dans des scripts". Le fait
que l'output soit sure une colonne quand stdout n'est pas un
terminal semble suggerer que c'est dans l'optique d'etre parsé
dans un script justement.

Voir aussi l'option --quoting-style du GNU ls.

ls peut etre utile avec l'option t (et u et c). Par ailleurs,
dans la boite a outil POSIX, ls est la seule commande disponible
pour obtenir des informations (taille, times, user,
permissions...) sur un fichier, meme si parser l'output de "ls
-l" fiablement et portablement est assez delicat. Il manque
cruellement une interface un peu plus scriptable aux appels
systeme stat(2) et lstat(2) (comme les differentes
implementations de stat(1) qu'on trouve ici et la ou le GNU find
-printf).

--
Stéphane

2008-10-20, 15:29(+02), 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.

non, zargs, c'est pour contourner la limitation de execve(2) de
certains systemes, ca ne s'applique pas ici, car il n'y a pas
execution de commande. L'expansion de "*" n'est pas passé comme
arguments d'une commande executee.

Par contre, en passant par un pipe, seul ls est utilisable,
ou find. Car '*' est interprété avant l'exécution de la commande.

Je ne vois pas ce que tu veux dire.

Si tu veux ecrire l'expansion de "*" dans un pipe, tu peux tres
bien faire:

printf '%sn' *

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.

for i in *

est tout indiqué pour faire une boucle sur la liste triee des
fichiers non-cachés du repertoire courant.

Je recommanderais d'ailleurs plutot:

for i in ./*

pour eviter les problemes avec les noms de fichier qui
commencent par "-" ou "+" ou qui contiennent un "=" par exemple.

--
Stéphane

Stephane CHAZELAS a écrit :

2008-10-18, 15:43(+02), Cyrille Lefevre:

[snip]

ls n'est pas fait pour les chiens. ls -1 non plus. Lorsque j'écri s

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.

bon, je me suis mal exprimé, mais dans le contexte $(ls)...

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.

Hugues wrote:

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 ?

xargs a une option -P qui n'a pas d'équivalent évident dans find (je dis
ça juste parce que ça fait une chose à demander...).

Marc wrote:

xargs a une option -P qui n'a pas d'équivalent évident dans find (je dis
ça juste parce que ça fait une chose à demander...).

Euh non, oubliez, ce n'est pas standard de toute façon.

2008-10-21, 11:18(+00), Marc:

Marc wrote:

xargs a une option -P qui n'a pas d'équivalent évident dans find (je dis
ça juste parce que ça fait une chose à demander...).

Euh non, oubliez, ce n'est pas standard de toute façon.

Il y a d'autres options qui n'ont pas d'equivalent, comme -n.

Les find de GNU ou de certains BSD ont une option -print0
compatible avec une option -0 de xargs, qui permet de les
utiliser fiablement l'un avec l'autre:

find ... -print0 | xargs -r0n3 cmd

Avec -exec, ca devient plus compliqué, faut faire quelquechose
comme:

find .... -exec sh -c '
while [ "$#" -ge 3 ]; do
cmd "$1" "$2" "$3"
shift 3
done
[ "$#" -eq 0 ] || cmd "$@"' inline {} +

Et encore, ca peut merdoyer si find lance plus d'un sh.

Il est aussi possible de faire des trucs du genre:

find .//. ... -print | sed 's/./\&/g' | awk '{
if (NR > 1) {
printf("%s", line)
if ($0 !~ /\/\//)
printf("\")
printf("n")
}
line = $0
}
END {
print(line)
}' | xargs -n3 cmd

Comme montré dans la page de man d'xargs du heirloom toolchest.

--
Stéphane