Ma remarque faisait référence au pipe, mais ce qui est réellement le plus gênant est de parser 2.5To de données. En plus, dans ta ligne de commande on le fait plusieurs fois, une première fois avec cat, tout ça passe dans le pipe, et ensuite traité par cut.
cat pi.txt | cut -c -4 -
^ ^
| |
| +---- données sortantes de pipe (stdout), toujours 2.5To
| qui deviennent les données entrantes (stdin) pour cut
|
données sortantes (stdout)
de cat 2.5To et données
entrantes de pipe (stdin)
la lecture du fichier est complète,
jusqu'à atteindre EOF
La suppression du pipe ne règle pas réellement le problème (au lieu de parser deux fois 2.5To de données on les parse qu'une seule fois).
Même avec cut -c -4 pi.txt | head -1cut va parser toutes les données et ensuite envoyé le peu de données (stdout provenant de cut) vers le pipe, et head recevra bien un minimum d'octet.
Dans ce cas on a gagné de ne pas envoyé 2.5To dans le pipe, par contre on a toujours lu le fichier en entier à cause du fonctionnement interne de cut, c'est pour cette raison qu'il faut faire appel à d'autres commandes qui ne font que lire le strict minimum de données qui nous sont réellement utile.
strace met en évidence le comportement interne de cut (head aurait un comportement similaire avec l'option -c) :
##### ouverture du fichier
open("pi.txt", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=10, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7840000
##### lecture des données : ici toutes avec l'exemple de fichier pi.txt
##### les 2.5To se retrouveront ici!
read(3, "3.14159265", 4096) = 10
#####
#####
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb783f000
##### traitement de la demande selon les paramètres passés en ligne de commande
read(3, "", 4096) = 0
##### écriture du résultat (ajout d'un saut de ligne) sur la sortie standard
write(1, "3.14\n", 53.14
À la base c'était juste pour rebondir sur ta "blague" :)
[^] # Re: Mensonge !
Posté par gnuk . En réponse à la dépêche Fabrice Bellard bat le record des décimales de Pi. Évalué à 3.
cut -c -4 pi.txt | head -1cut va parser toutes les données et ensuite envoyé le peu de données (stdout provenant de cut) vers le pipe, et head recevra bien un minimum d'octet. Dans ce cas on a gagné de ne pas envoyé 2.5To dans le pipe, par contre on a toujours lu le fichier en entier à cause du fonctionnement interne de cut, c'est pour cette raison qu'il faut faire appel à d'autres commandes qui ne font que lire le strict minimum de données qui nous sont réellement utile. strace met en évidence le comportement interne de cut (head aurait un comportement similaire avec l'option -c) :##### ouverture du fichier open("pi.txt", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=10, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7840000 ##### lecture des données : ici toutes avec l'exemple de fichier pi.txt ##### les 2.5To se retrouveront ici! read(3, "3.14159265", 4096) = 10 ##### ##### fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb783f000 ##### traitement de la demande selon les paramètres passés en ligne de commande read(3, "", 4096) = 0 ##### écriture du résultat (ajout d'un saut de ligne) sur la sortie standard write(1, "3.14\n", 53.14À la base c'était juste pour rebondir sur ta "blague" :)