Le 16/10/2011 18:59, nt.guilde@??? a écrit :
>>> J'ai également eu des problèmes de ce type avec un for FILE in `ls
>>> truc*`. Explosion quand il y a plusieurs dizaines de milliers de
>>> fichiers :). Ça doit être le wildcard qui déconne...
>>
>> C'est pas le wildcard qui déconne, mais la limite du buffer d'entrée d'une
>> ligne de shell...
>
> Mais 'bash' n'a pas de limites ; exemple :
>
> $ for i in `yes alpha | dd bs=6 count=10000000 2>/dev/null` ; do
>> echo $i
>> done | wc
> 10000000 10000000 60000000
>
> Ici, la liste des 10^7 mots occupe 6*10^7 octets.
> Est-ce que vous pourriez retrouver l'erreur exacte que vous avez reçue ?
Je n'ai malheureusement pas gardé le message d'erreur, mais il me semble
bien que j'avais une erreur du "buffer d'entrée d'une ligne de shell"
comme l'indique Frédéric.
Aujourd'hui, vu ce qui est dit sur BashPitfalls [1], je préfère
continuer à utiliser while:
«
The final issue with reading lines with for is inefficiency. A while
read loop reads one line at a time from an input stream; $(<afile)
slurps the entire file into memory all at once. For small files, this is
not a problem, but if you're reading large files, the memory requirement
will be enormous. (Bash will have to allocate one string to hold the
file, and another set of strings to hold the word-split results...
essentially, the memory allocated will be twice the size of the input file.)
»
De ce que je comprends, for charge tout en mémoire, tandis qu'un while
charge une seule ligne à la fois…
Après, je ne saisis peut-être pas toutes les subtilités du shell: j'ai
comme l'impression que la façon de définir l'ensemble utilisé par for
est déterminante.
Je n'ai pas réussi à reproduire l'erreur… :-(
Peut-être aussi que cela dépend du shell utilisé (j'avais eu l'erreur
sur un serveur Sun) ?
[1]
http://mywiki.wooledge.org/DontReadLinesWithFor
(Merci Vincent pour cette excellente référence !)
@+
Fernando
