Ich habe gerade den Kommentar über MacOS bemerkt, und obwohl ich denke, dass die Lösung von @akira (und pv) viel ordentlicher ist, dachte ich, ich würde einer Vermutung nachgehen und einen schnellen Playaround in meiner MacOS-Box mit tar und dem Senden eines SIGINFO-Signals durchführen. Lustigerweise hat es funktioniert :) wenn Sie auf einem BSD-ähnlichen System sind, sollte das funktionieren, aber auf einem Linux-Rechner müssen Sie vielleicht ein SIGUSR1 senden, und/oder tar funktioniert vielleicht nicht auf die gleiche Weise.
Der Nachteil ist, dass es Ihnen nur eine Ausgabe (auf stdout) liefert, die Ihnen zeigt, wie weit es mit der aktuellen Datei ist, da ich vermute, dass es keine Ahnung hat, wie groß der Datenstrom ist, den es bekommt.
Also ja, eine alternative Herangehensweise wäre, tar zu starten und ihm periodisch SIGINFOs zu schicken, wann immer Sie wissen wollen, wie weit es gekommen ist. Wie man das macht?
Der ad-hoc, manuelle Ansatz
Wenn Sie in der Lage sein wollen, den Status ad-hoc zu überprüfen, können Sie control-T (wie Brian Swift erwähnte) im entsprechenden Fenster drücken, was das SIGINFO-Signal sendet. Ein Problem dabei ist, dass es an die gesamte Kette gesendet wird, wenn Sie also Folgendes tun:
% tar cvf - folder-with-big-files | bzip2 -c > big-files.tar.bz2
Sie werden auch sehen, dass bzip2 seinen Status zusammen mit tar meldet:
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)
Das funktioniert gut, wenn Sie nur überprüfen wollen, ob das tar, das Sie ausführen, feststeckt oder einfach langsam ist. Sie müssen sich in diesem Fall wahrscheinlich nicht allzu viele Gedanken über Formatierungsprobleme machen, da es sich nur um eine schnelle Überprüfung handelt.
Die Art von automatisiertem Ansatz
Wenn Sie wissen, dass es eine Weile dauern wird, aber so etwas wie eine Fortschrittsanzeige wollen, wäre eine Alternative, Ihren tar-Prozess zu starten und in einem anderen Terminal seine PID zu ermitteln und diese dann in ein Skript zu werfen, das einfach wiederholt ein Signal sendet. Wenn Sie zum Beispiel das folgende Skriptlet haben (und es als script.sh PID-to-signal interval-to-signal-at aufrufen):
#!/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?"
Wenn Sie es auf diese Weise aufrufen, erhalten Sie, da Sie nur auf tar abzielen, eher eine Ausgabe wie diese
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)
...
, was zugegebenermaßen ziemlich hübsch ist.
Zu guter Letzt - mein Skripting ist etwas eingerostet, wenn also jemand den Code aufräumen/verbessern möchte, nur zu :)