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
À (at) Sat, 18 Oct 2008 15:43:37 +0200, Cyrille Lefevre <cyrille.lefevre-news% écrivait (wrote):
JKB a écrit :
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.
Et surtout, il n'y a pas que les alias. Il y a aussi les fonctions. Dans ma config, 'ls' est une fonction. Dans ce cas le 'unalias' n'est pas suffisant !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sat, 18 Oct 2008 15:43:37 +0200,
Cyrille Lefevre <cyrille.lefevre-news%nospam@laposte.net.invalid> écrivait (wrote):
JKB a écrit :
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 <slrngfj5ah.gq7.knatschke@rayleigh.systella.fr>:
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.
Et surtout, il n'y a pas que les alias. Il y a aussi les
fonctions. Dans ma config, 'ls' est une fonction. Dans ce cas le
'unalias' n'est pas suffisant !
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sat, 18 Oct 2008 15:43:37 +0200, Cyrille Lefevre <cyrille.lefevre-news% écrivait (wrote):
JKB a écrit :
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.
Et surtout, il n'y a pas que les alias. Il y a aussi les fonctions. Dans ma config, 'ls' est une fonction. Dans ce cas le 'unalias' n'est pas suffisant !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
JKB
Le 18-10-2008, ? propos de Re: convertir en utf-8 en masse, Paul Gaborit ?crivait dans fr.comp.os.unix :
À (at) Sat, 18 Oct 2008 15:43:37 +0200, Cyrille Lefevre <cyrille.lefevre-news% écrivait (wrote):
JKB a écrit :
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.
Et surtout, il n'y a pas que les alias. Il y a aussi les fonctions. Dans ma config, 'ls' est une fonction. Dans ce cas le 'unalias' n'est pas suffisant !
Nous sommes d'accord. D'un autre côté, si on s'amuse à redéfinir les commandes de base, on ne risque plus d'écrire grand chose ;-)
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 18-10-2008, ? propos de
Re: convertir en utf-8 en masse,
Paul Gaborit ?crivait dans fr.comp.os.unix :
À (at) Sat, 18 Oct 2008 15:43:37 +0200,
Cyrille Lefevre <cyrille.lefevre-news%nospam@laposte.net.invalid> écrivait (wrote):
JKB a écrit :
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 <slrngfj5ah.gq7.knatschke@rayleigh.systella.fr>:
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.
Et surtout, il n'y a pas que les alias. Il y a aussi les
fonctions. Dans ma config, 'ls' est une fonction. Dans ce cas le
'unalias' n'est pas suffisant !
Nous sommes d'accord. D'un autre côté, si on s'amuse à redéfinir les
commandes de base, on ne risque plus d'écrire grand chose ;-)
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 18-10-2008, ? propos de Re: convertir en utf-8 en masse, Paul Gaborit ?crivait dans fr.comp.os.unix :
À (at) Sat, 18 Oct 2008 15:43:37 +0200, Cyrille Lefevre <cyrille.lefevre-news% écrivait (wrote):
JKB a écrit :
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.
Et surtout, il n'y a pas que les alias. Il y a aussi les fonctions. Dans ma config, 'ls' est une fonction. Dans ce cas le 'unalias' n'est pas suffisant !
Nous sommes d'accord. D'un autre côté, si on s'amuse à redéfinir les commandes de base, on ne risque plus d'écrire grand chose ;-)
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.
Nicolas George
JKB wrote in message :
Maintenant, ce n'est peut-être pas portable
C'est non seulement non portable mais complètement non standard. Je ne sais pas quels sévices tu as fait subir à ton shell pour en arriver là, mais tu as de la chance de ne pas être tombé sur des cas où ça ruine complètement d'autres comportements.
Et en particulier, tu devrais t'abstenir de supposer que ce comportement est partagé par quiconque.
JKB wrote in message <slrngfjci8.gq7.knatschke@rayleigh.systella.fr>:
Maintenant, ce n'est peut-être pas portable
C'est non seulement non portable mais complètement non standard. Je ne sais
pas quels sévices tu as fait subir à ton shell pour en arriver là, mais tu
as de la chance de ne pas être tombé sur des cas où ça ruine complètement
d'autres comportements.
Et en particulier, tu devrais t'abstenir de supposer que ce comportement est
partagé par quiconque.
C'est non seulement non portable mais complètement non standard. Je ne sais pas quels sévices tu as fait subir à ton shell pour en arriver là, mais tu as de la chance de ne pas être tombé sur des cas où ça ruine complètement d'autres comportements.
Et en particulier, tu devrais t'abstenir de supposer que ce comportement est partagé par quiconque.
Thierry B.
--{ JKB a plopé ceci: }--
for i in $(ls); do iconv ...; done ?
Flagrant délit de UUOL, vot' compte est bon!
-- alias ps='ps axo "user,pid,ppid,%cpu,%mem,tty,start,state,command"'
--{ JKB a plopé ceci: }--
for i in $(ls); do iconv ...; done ?
Flagrant délit de UUOL, vot' compte est bon!
--
alias ps='ps axo "user,pid,ppid,%cpu,%mem,tty,start,state,command"'
Ne serait-ce pas que ton nouvelleur t'affiche des souriards intempestifs en lieu et place de certaines combinaisons de points, de parenthèses ou d'autres signes de ponctuation ?
Sinon il y a l'aéroport de Lipetsk ou bien http://www.uuol.net/ mais je vois encore moins le rapport.
Ne serait-ce pas que ton nouvelleur t'affiche des souriards intempestifs
en lieu et place de certaines combinaisons de points, de parenthèses ou
d'autres signes de ponctuation ?
Sinon il y a l'aéroport de Lipetsk ou bien http://www.uuol.net/ mais je
vois encore moins le rapport.
Ne serait-ce pas que ton nouvelleur t'affiche des souriards intempestifs en lieu et place de certaines combinaisons de points, de parenthèses ou d'autres signes de ponctuation ?
Sinon il y a l'aéroport de Lipetsk ou bien http://www.uuol.net/ mais je vois encore moins le rapport.
Che Averell
Olivier Miakinen <om+ écrit :
'lu Olivier,
Flagrant délit de UUOL, vot' compte est bon!
<snip>
Sinon il y a l'aéroport de Lipetsk ou bien http://www.uuol.net/ mais je vois encore moins le rapport.
En fait, non, c'est pas ça. UUOL : Useless Use Of Ls. C'est une repompe du célèbre UUOC. http://fr.wikipedia.org/wiki/UUOC#Cat_et_UUOC
Olivier Miakinen <om+news@miakinen.net> écrit :
'lu Olivier,
Flagrant délit de UUOL, vot' compte est bon!
<snip>
Sinon il y a l'aéroport de Lipetsk ou bien http://www.uuol.net/ mais je
vois encore moins le rapport.
En fait, non, c'est pas ça. UUOL : Useless Use Of Ls. C'est une
repompe du célèbre UUOC.
http://fr.wikipedia.org/wiki/UUOC#Cat_et_UUOC
En fait, non, c'est pas ça. UUOL : Useless Use Of Ls. C'est une repompe du célèbre UUOC. http://fr.wikipedia.org/wiki/UUOC#Cat_et_UUOC
Merci ! Je ne connaissais pas. Au fait, en suivant le lien vers « UUOC Award » on trouve ceci : <http://partmaps.org/era/unix/award.html#ls>.
Stephane CHAZELAS
2008-10-18, 08:05(+00), Nicolas George:
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.
Pas dans un script, heureusement! Les shells qui interpretent les scripts ne lisent pas les fichiers de configuration interactive.
2. ls formate son affichage, en particulier pour les caractères spéciaux et en fonction de la locale, ce qui rend sa sortie inutilisable en toute généralité.
Par quand sa stdout est un pipe.
3. Le fait de reparser la sortie d'une commande perd l'information de la limite des noms de fichiers.
Oui, c'est le principal probleme.
Il faudrait faire:
IFS=' ' set -f for i in $(ls)
mais ca ne marche plus des que les noms de fichiers contiennent des saut de ligne.
Un des problemes avec
for i in *
C'est que s'il n'y a pas de fichier, ca fait une passe dans la boucle avec la valeur "*"!
On peut l'eviter avec bash ou zsh, mais ce ne sera pas standard. Il faut alors recourir a:
set -- [*] * case $1$2 in ("[*]*") ;; (*) shift for i do ... done esac
On peut aussi utiliser find:
find . ! -name . -prune -exec cmd {} ;
Qui a aussi l'avantage d'inclure les fichiers cachés hormis "." et ".." et ne perd pas son temps a trier les fichiers quand on n'en a pas besoin.
-- Stéphane
2008-10-18, 08:05(+00), Nicolas George:
JKB wrote in message <slrngfj5ah.gq7.knatschke@rayleigh.systella.fr>:
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.
Pas dans un script, heureusement! Les shells qui interpretent les
scripts ne lisent pas les fichiers de configuration interactive.
2. ls formate son affichage, en particulier pour les caractères spéciaux et
en fonction de la locale, ce qui rend sa sortie inutilisable en toute
généralité.
Par quand sa stdout est un pipe.
3. Le fait de reparser la sortie d'une commande perd l'information de la
limite des noms de fichiers.
Oui, c'est le principal probleme.
Il faudrait faire:
IFS='
'
set -f
for i in $(ls)
mais ca ne marche plus des que les noms de fichiers contiennent
des saut de ligne.
Un des problemes avec
for i in *
C'est que s'il n'y a pas de fichier, ca fait une passe dans la
boucle avec la valeur "*"!
On peut l'eviter avec bash ou zsh, mais ce ne sera pas standard.
Il faut alors recourir a:
set -- [*] *
case $1$2 in
("[*]*") ;;
(*) shift
for i do
...
done
esac
On peut aussi utiliser find:
find . ! -name . -prune -exec cmd {} ;
Qui a aussi l'avantage d'inclure les fichiers cachés hormis "."
et ".." et ne perd pas son temps a trier les fichiers quand on
n'en a pas besoin.
1. ls est très souvent aliasé, ce qui peut rendre inutilisable sa sortie pour un script.
Pas dans un script, heureusement! Les shells qui interpretent les scripts ne lisent pas les fichiers de configuration interactive.
2. ls formate son affichage, en particulier pour les caractères spéciaux et en fonction de la locale, ce qui rend sa sortie inutilisable en toute généralité.
Par quand sa stdout est un pipe.
3. Le fait de reparser la sortie d'une commande perd l'information de la limite des noms de fichiers.
Oui, c'est le principal probleme.
Il faudrait faire:
IFS=' ' set -f for i in $(ls)
mais ca ne marche plus des que les noms de fichiers contiennent des saut de ligne.
Un des problemes avec
for i in *
C'est que s'il n'y a pas de fichier, ca fait une passe dans la boucle avec la valeur "*"!
On peut l'eviter avec bash ou zsh, mais ce ne sera pas standard. Il faut alors recourir a:
set -- [*] * case $1$2 in ("[*]*") ;; (*) shift for i do ... done esac
On peut aussi utiliser find:
find . ! -name . -prune -exec cmd {} ;
Qui a aussi l'avantage d'inclure les fichiers cachés hormis "." et ".." et ne perd pas son temps a trier les fichiers quand on n'en a pas besoin.
-- Stéphane
Stephane CHAZELAS
2008-10-18, 08:35(+00), JKB:
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 un script, j'ai toujours un unalias -a au début. Pourquoi ? Parce que j'ai déjà vu des trucs rigolo avec des commandes de base ayant été 'aliassisées' de façon totalement baroque.
S'il y a des alias defini dans un script, l'utilisateur doit avec de bonnes raisons d'avoir reussi a faire en sorte que ce soit le cas (a moins que tu ne parles de csh), auquel cas ton script ne devrait pas essayer de faire de zele.
2. ls formate son affichage, en particulier pour les caractères spéciaux et en fonction de la locale, ce qui rend sa sortie inutilisable en toute généralité.
Tous les scripts shell commencent par une déclaration de locale, et tant qu'on y est, C (parce que là encore...). Si tu ne fais pas ça, tu risques fort d'aller dans le mur très vite parce que le nombre de commandes ayant une sortie localisée est assez grand.
Si tu redefinis la locale au debut, tu perds l'information de la locale de l'utilisateur.
3. Le fait de reparser la sortie d'une commande perd l'information de la limite des noms de fichiers.
Non, parce qu'il y a des caractères 'n'. Si vraiment tu as peur de ça, tu colles un coup de awk et on n'en parle plus.
Tu veux dire faire ls -d .//* | awk '...'
Dans ce cas tu utilises le globbing du shell, donc pourquoi ne pas se debarrasser du ls qui est redondant ici.
Ce que je dis là, c'est la base de la base de l'écriture de scripts shells Unix. Si tu ne le savais pas déjà, c'est inquiétant.
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, mais c'est toi qui voit.
Quel genre de merdoiement? Je ne connais pas de shell ou systeme qui ait de probleme avec ca.
-- Stéphane
2008-10-18, 08:35(+00), JKB:
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 <slrngfj5ah.gq7.knatschke@rayleigh.systella.fr>:
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
un script, j'ai toujours un unalias -a au début. Pourquoi ? Parce
que j'ai déjà vu des trucs rigolo avec des commandes de base ayant
été 'aliassisées' de façon totalement baroque.
S'il y a des alias defini dans un script, l'utilisateur doit
avec de bonnes raisons d'avoir reussi a faire en sorte que ce
soit le cas (a moins que tu ne parles de csh), auquel cas ton
script ne devrait pas essayer de faire de zele.
2. ls formate son affichage, en particulier pour les caractères spéciaux et
en fonction de la locale, ce qui rend sa sortie inutilisable en toute
généralité.
Tous les scripts shell commencent par une déclaration de locale, et
tant qu'on y est, C (parce que là encore...). Si tu ne fais pas ça,
tu risques fort d'aller dans le mur très vite parce que le nombre de
commandes ayant une sortie localisée est assez grand.
Si tu redefinis la locale au debut, tu perds l'information de la
locale de l'utilisateur.
3. Le fait de reparser la sortie d'une commande perd l'information de la
limite des noms de fichiers.
Non, parce qu'il y a des caractères 'n'. Si vraiment tu as peur de
ça, tu colles un coup de awk et on n'en parle plus.
Tu veux dire faire ls -d .//* | awk '...'
Dans ce cas tu utilises le globbing du shell, donc pourquoi ne
pas se debarrasser du ls qui est redondant ici.
Ce que je dis là, c'est la base de la base de l'écriture de scripts shells
Unix. Si tu ne le savais pas déjà, c'est inquiétant.
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,
mais c'est toi qui voit.
Quel genre de merdoiement? Je ne connais pas de shell ou systeme
qui ait de probleme avec ca.
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 un script, j'ai toujours un unalias -a au début. Pourquoi ? Parce que j'ai déjà vu des trucs rigolo avec des commandes de base ayant été 'aliassisées' de façon totalement baroque.
S'il y a des alias defini dans un script, l'utilisateur doit avec de bonnes raisons d'avoir reussi a faire en sorte que ce soit le cas (a moins que tu ne parles de csh), auquel cas ton script ne devrait pas essayer de faire de zele.
2. ls formate son affichage, en particulier pour les caractères spéciaux et en fonction de la locale, ce qui rend sa sortie inutilisable en toute généralité.
Tous les scripts shell commencent par une déclaration de locale, et tant qu'on y est, C (parce que là encore...). Si tu ne fais pas ça, tu risques fort d'aller dans le mur très vite parce que le nombre de commandes ayant une sortie localisée est assez grand.
Si tu redefinis la locale au debut, tu perds l'information de la locale de l'utilisateur.
3. Le fait de reparser la sortie d'une commande perd l'information de la limite des noms de fichiers.
Non, parce qu'il y a des caractères 'n'. Si vraiment tu as peur de ça, tu colles un coup de awk et on n'en parle plus.
Tu veux dire faire ls -d .//* | awk '...'
Dans ce cas tu utilises le globbing du shell, donc pourquoi ne pas se debarrasser du ls qui est redondant ici.
Ce que je dis là, c'est la base de la base de l'écriture de scripts shells Unix. Si tu ne le savais pas déjà, c'est inquiétant.
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, mais c'est toi qui voit.
Quel genre de merdoiement? Je ne connais pas de shell ou systeme qui ait de probleme avec ca.
-- Stéphane
Stephane CHAZELAS
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.
Note que $(ls -1) est la meme chose que $(ls). D'abord parce que quand le stdout de ls est un pipe, il l'affiche sur une colonne de toute facon (-1 ou pas), ensuite meme si ce n'etait pas le cas. $(...) decoupe par defaut suivant les blancs, pas seulement les sauts de lignes. A noter que $(...) expande les wildcards, donc si ls -1 afficher "a * b", ca loop sur "a", la liste des fichiers du repertoire et "b". C'est pourquoi on ecrit:
IFS=' ' # decoupe seulement suivant les sauts de ligne. set -f # disable globbing for i in $(ls)
qui presuppose que les noms de fichier ne contiennent pas de newlines.
-- Stéphane
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.
Note que $(ls -1) est la meme chose que $(ls). D'abord parce que
quand le stdout de ls est un pipe, il l'affiche sur une colonne
de toute facon (-1 ou pas), ensuite meme si ce n'etait pas le
cas. $(...) decoupe par defaut suivant les blancs, pas seulement
les sauts de lignes. A noter que $(...) expande les wildcards,
donc si ls -1 afficher "a * b", ca loop sur "a", la liste des
fichiers du repertoire et "b". C'est pourquoi on ecrit:
IFS='
' # decoupe seulement suivant les sauts de ligne.
set -f # disable globbing
for i in $(ls)
qui presuppose que les noms de fichier ne contiennent pas de
newlines.
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.
Note que $(ls -1) est la meme chose que $(ls). D'abord parce que quand le stdout de ls est un pipe, il l'affiche sur une colonne de toute facon (-1 ou pas), ensuite meme si ce n'etait pas le cas. $(...) decoupe par defaut suivant les blancs, pas seulement les sauts de lignes. A noter que $(...) expande les wildcards, donc si ls -1 afficher "a * b", ca loop sur "a", la liste des fichiers du repertoire et "b". C'est pourquoi on ecrit:
IFS=' ' # decoupe seulement suivant les sauts de ligne. set -f # disable globbing for i in $(ls)
qui presuppose que les noms de fichier ne contiennent pas de newlines.
