Je viens de remarquer le commentaire sur MacOS, et bien que je pense que la solution de @akira (et pv) est complètement plus propre, j'ai pensé que je pourrais suivre une intuition et une rapide mise au point dans ma boîte MacOS avec du goudron et lui envoyer un signal SIGINFO. Curieusement, ça a marché :) si vous êtes sur un système de type BSD, cela devrait fonctionner, mais sur une machine Linux, vous pourriez avoir besoin d'envoyer un SIGUSR1, et/ou tar pourrait ne pas fonctionner de la même manière.
L'inconvénient est qu'il ne vous fournira qu'une sortie (sur stdout) vous montrant à quelle distance se trouve le fichier actuel, car je suppose qu'il n'a aucune idée de la taille du flux de données qu'il reçoit.
Donc oui, une approche alternative serait d'allumer le goudron et de lui envoyer périodiquement des SIGINFOs chaque fois que vous voulez savoir jusqu'où il est arrivé. Comment faire ?
L'approche manuelle ad hoc
Si vous voulez être en mesure de vérifier le statut de manière ad hoc, vous pouvez appuyer sur control-T (comme Brian Swift l'a mentionné) dans la fenêtre correspondante qui enverra le signal SIGINFO. Le problème, c'est que cela va l'envoyer à toute votre chaîne, je crois, donc si vous le faites :
% tar cvf - folder-with-big-files | bzip2 -c > big-files.tar.bz2
Vous verrez également bzip2 signaler son statut avec le goudron :
a folder-with-big-files/big-file.imgload 0.79 cmd: bzip2 13325 running
14 0.27u 1.02s
adding folder-with-big-files/big-file.imgload (17760256 / 32311520)
Cela fonctionne bien si vous voulez juste vérifier si le tar que vous exécutez est bloqué, ou juste lent. Dans ce cas, vous n'avez probablement pas à vous soucier de problèmes de formatage, puisqu'il ne s'agit que d'une vérification rapide..
Le genre d'approche automatisée
Si vous savez que cela va prendre un certain temps, mais que vous voulez quelque chose comme un indicateur de progrès, une alternative serait de lancer votre processus de goudron et dans un autre terminal, de calculer son PID et de le lancer dans un script qui envoie un signal répété. Par exemple, si vous avez le scriptlet suivant (et que vous l'invoquez en disant script.sh PID-to-signal interval-to-signal-at) :
#!/bin/sh
PID=$1
INTERVAL=$2
SIGNAL=29 # excuse the voodoo, bash gets the translation of SIGINFO,
# sh won't..
kill -0 $PID # invoke a quick check to see if the PID is present AND that
# you can access it..
echo "this process is $$, sending signal $SIGNAL to $PID every $INTERVAL s"
while [$? -eq 0]; do
sleep $INTERVAL;
kill -$SIGNAL $PID; # The kill signalling must be the last statement
# or else the $? conditional test won't work
done
echo "PID $PID no longer accessible, tar finished?"
Si vous l'invoquez de cette façon, puisque vous ne visez que tar vous obtiendrez une sortie plus semblable à celle-ci
a folder-with-big-files/tinyfile.1
a folder-with-big-files/tinyfile.2
a folder-with-big-files/tinyfile.3
a folder-with-big-files/bigfile.1
adding folder-with-big-files/bigfile.1 (124612 / 94377241)
adding folder-with-big-files/bigfile.1 (723612 / 94377241)
...
qui, je l'admets, est plutôt jolie.
Enfin et surtout, mon script est un peu rouillé, donc si quelqu'un veut aller nettoyer/réparer/améliorer le code, allez-y pour votre vie :)