Is there a way to see any tar progress per file?
I have a couple of big files that I would like to compress. I can do this with for example
tar cvfj big-files.tar.bz2 folder-with-big-files
The problem is that I can't see any progress, so I don't have a clue how long it will take or anything like that. Using v
I can at least see when each file is completed, but when the files are few and large this isn't the most helpful.
Is there a way I can get tar to show more detailed progress? Like a percentage done or a progress bar or estimated time left or something. Either for each single file or all of them or both.
unix tar progress
add a comment |
I have a couple of big files that I would like to compress. I can do this with for example
tar cvfj big-files.tar.bz2 folder-with-big-files
The problem is that I can't see any progress, so I don't have a clue how long it will take or anything like that. Using v
I can at least see when each file is completed, but when the files are few and large this isn't the most helpful.
Is there a way I can get tar to show more detailed progress? Like a percentage done or a progress bar or estimated time left or something. Either for each single file or all of them or both.
unix tar progress
add a comment |
I have a couple of big files that I would like to compress. I can do this with for example
tar cvfj big-files.tar.bz2 folder-with-big-files
The problem is that I can't see any progress, so I don't have a clue how long it will take or anything like that. Using v
I can at least see when each file is completed, but when the files are few and large this isn't the most helpful.
Is there a way I can get tar to show more detailed progress? Like a percentage done or a progress bar or estimated time left or something. Either for each single file or all of them or both.
unix tar progress
I have a couple of big files that I would like to compress. I can do this with for example
tar cvfj big-files.tar.bz2 folder-with-big-files
The problem is that I can't see any progress, so I don't have a clue how long it will take or anything like that. Using v
I can at least see when each file is completed, but when the files are few and large this isn't the most helpful.
Is there a way I can get tar to show more detailed progress? Like a percentage done or a progress bar or estimated time left or something. Either for each single file or all of them or both.
unix tar progress
unix tar progress
edited Oct 19 '12 at 5:21
Journeyman Geek♦
113k44217371
113k44217371
asked Jul 28 '10 at 11:51
SvishSvish
16.6k54109168
16.6k54109168
add a comment |
add a comment |
10 Answers
10
active
oldest
votes
I prefer oneliners like this:
tar cf - /folder-with-big-files -P | pv -s $(du -sb /folder-with-big-files | awk '{print $1}') | gzip > big-files.tar.gz
It will have output like this:
4.69GB 0:04:50 [16.3MB/s] [==========================> ] 78% ETA 0:01:21
For OSX (from Kenji's answer)
tar cf - /folder-with-big-files -P | pv -s $(($(du -sk /folder-with-big-files | awk '{print $1}') * 1024)) | gzip > big-files.tar.gz
2
On OSX, du does not take -b argument, needed to fallback to : $((du -sk /folder-with | awk '{print $1}') * 1024))
– ıɾuǝʞ
Nov 29 '13 at 10:14
4
Nice, a one liner. Can you explain it? Or does it just magically work somehow?
– Kissaki
Oct 4 '14 at 18:02
Can you write command to extract tar file like above?
– Krzysztof Szewczyk
Nov 26 '14 at 13:47
2
Ok, I have itpv $FILE.tgz | tar xzf - -C $DEST_DIR
– Krzysztof Szewczyk
Nov 28 '14 at 7:57
1
okay I figured it out thanks to this : stackoverflow.com/a/19372542/4770754 , it's :pv archive.tar.xz | tar xp -J -C ~/location
– tatsu
Mar 8 at 10:19
|
show 8 more comments
You can use pv to achieve this. To report the progress correctly, pv
needs to know how much bytes you are throwing at it. So, the first step is to calculate the size (in kbyte). You can also completely drop the progress bar and just let pv
tell you how much bytes it has seen; it would report a 'done that much and that fast'.
% SIZE=`du -sk folder-with-big-files | cut -f 1`
And then:
% tar cvf - folder-with-big-files | pv -p -s ${SIZE}k |
bzip2 -c > big-files.tar.bz2
Cool.pv
doesn't seem to come with Mac OS X, but will try this out once I have a computer with MacPorts on it. Could you explain what you are doing there though? Not quite sure what the first line does exactly.
– Svish
Jul 28 '10 at 12:10
4
first line: fetch info about how many bytes will be handled. second line: use the size from the first line to allow pv to render 'progress'. since you are piping data, pv does not know how many more bytes will come.
– akira
Jul 22 '11 at 10:25
One addition:SIZE=$(($SIZE * 1000 / 1024))
- I don't know whether or not this is a quirk on my particular platform, so I'm not adding it to the answer:du
returns size where 1 kb = 1024 bytes, whilepv
seems to be expecting 1 kb = 1000 bytes. (I'm on Ubuntu 10.04)
– Izkata
Dec 11 '11 at 2:27
2
@lzkata you could always askdu
to use your preferred blocksize, e.g.du -s --block-size=1000
, or just work with plain bytes, e.g. drop thek
's from thedu
andpv
calls. Nevertheless, I would expect both to use1024
unless told otherwise, e.g. the--si
switch ondu
, for example.
– Legolas
Feb 23 '12 at 11:05
1
or just drop the k-stuff and just use plain bytes (du -sb
andpv -s
without any modifier). that should end all the confusion.
– akira
Feb 23 '12 at 11:10
|
show 1 more comment
better progress bar..
apt-get install pv dialog
(pv -n file.tgz | tar xzf - -C target_directory )
2>&1 | dialog --gauge "Extracting file..." 6 50
2
This is works for extraction, but you still need to do one of the more complicated commands for creation (which was the original question). It could still be combined with those; it's just more complicated.
– Daniel H
Aug 9 '14 at 5:05
add a comment |
Check out the --checkpoint
and --checkpoint-action
options in the tar info page (as for my distribution, the description for these options is not contained in the man page → RTFI).
See https://www.gnu.org/software/tar/manual/html_section/tar_26.html
With these (and maybe the functionality to write your own checkpoint command), you can calculate a percentage…
2
This should be the correct answer. Others just explain extra tools (not installed by default, besides) to achieve something similar.
– Carmine Giangregorio
Nov 15 '16 at 14:47
@Sardathrion Maybe because it's GNU-tar
specific.
– phk
Feb 24 '17 at 11:52
add a comment |
Inspired by helper’s answer
Another way is use the native tar
options
FROMSIZE=`du -sk ${FROMPATH} | cut -f 1`;
CHECKPOINT=`echo ${FROMSIZE}/50 | bc`;
echo "Estimated: [==================================================]";
echo -n "Progess: [";
tar -c --record-size=1K --checkpoint="${CHECKPOINT}" --checkpoint-action="ttyout=>" -f - "${FROMPATH}" | bzip2 > "${TOFILE}";
echo "]"
the result is like
Estimated: [==================================================]
Progess: [>>>>>>>>>>>>>>>>>>>>>>>
a complete example here
add a comment |
Just noticed the comment about MacOS, and while I think the solution from @akira (and pv) is much neater I thought I'd chase a hunch and a quick playaround in my MacOS box with tar and sending it a SIGINFO signal. Funnily enough, it worked :) if you're on a BSD-like system, this should work, but on a Linux box, you might need to send a SIGUSR1, and/or tar
might not work the same way.
The down side is that it will only provide you with an output (on stdout) showing you how far through the current file it is since I'm guessing it has no idea about how big the data stream it's getting is.
So yes, an alternative approach would be to fire up tar and periodically send it SIGINFOs anytime you want to know how far it's gotten. How to do this?
The ad-hoc, manual approach
If you want to be able to check status on an ad-hoc basis, you can hit control-T
(as Brian Swift mentioned) in the relevant window which will send the SIGINFO signal across. One issue with that is it will send it to your entire chain I believe, so if you are doing:
% tar cvf - folder-with-big-files | bzip2 -c > big-files.tar.bz2
You will also see bzip2 report it's status along with tar:
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)
This works nicely if you just want to check if that tar
you're running is stuck, or just slow. You probably don't need to worry too much about formatting issues in this case, since it's only a quick check..
The sort of automated approach
If you know it's going to take a while, but want something like a progress indicator, an alternative would be to fire off your tar process and in another terminal work out it's PID and then throw it into a script that just repeatedly sends a signal over. For example, if you have the following scriptlet (and invoke it as say 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?"
If you invoke it this way, since you're targeting only tar
you'll get an output more like this
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)
...
which I admit, is kinda pretty.
Last but not least - my scripting is kinda rusty, so if anyone wants to go in and clean up/fix/improve the code, go for your life :)
2
If runningtar
on the command line, typingcontrol-T
will send it a SIGINFO. If this was in a script it would be done withkill -INFO pid
– Brian Swift
Apr 23 '12 at 4:58
Completely forgot aboutcontrol-T
, I clearly have gotten used to spamming too many console windows for my own good..
– tanantish
Apr 23 '12 at 20:21
1
why can't I see -SIGINFO when doingkill -l
– Felipe Alvarez
Jun 12 '13 at 2:32
add a comment |
Inspired by Noah Spurrier’s answer
function tar {
local bf so
so=${*: -1}
case $(file "$so" | awk '{print$2}') in
XZ) bf=$(xz -lv "$so" |
perl -MPOSIX -ane '$.==11 && print ceil $F[5]/50688') ;;
gzip) bf=$(gzip -l "$so" |
perl -MPOSIX -ane '$.==2 && print ceil $F[1]/50688') ;;
directory) bf=$(find "$so" -type f | xargs du -B512 --apparent-size |
perl -MPOSIX -ane '$bk += $F[0]+1; END {print ceil $bk/100}') ;;
esac
command tar "$@" --blocking-factor=$bf
--checkpoint-action='ttyout=%u%r' --checkpoint=1
}
Source
17
A little context and explanation maybe?
– Kissaki
Oct 4 '14 at 18:03
add a comment |
Using only tar
tar
has the option (since v1.12) to print status information on signals using --totals=$SIGNO
, e.g.:
tar --totals=USR1 -czf output.tar input.file
Total bytes written: 6005319680 (5.6GiB, 23MiB/s)
The Total bytes written: [...]
information gets printed on every USR1 signal, e.g.:
pkill -SIGUSR1 tar
Source:
- gnu.org - GNU tar - 3.7 Checking tar progress
- gnu.org - tar - NEWS
add a comment |
If you known the file number instead of total size of all of them:
an alternative (less accurate but suitable) is to use the -l option and send in the unix pipe the filenames instead of data content.
Let's have 12345 files into mydir, command is:
[myhost@myuser mydir]$ tar cfvz ~/mytarfile.tgz .|pv -s 12345 -l > /dev/null
you can know such value in advance (because of your use case) or use some command like find+wc to discover it:
[myhost@myuser mydir]$ find | wc -l
12345
So, why not put this command into sub-command? =)
– Kirby
Jan 9 '18 at 14:12
tar cfvz ~/mytarfile.tgz . | pv -s $(find . | wc -l) -l > /dev/null
. Does it work for you?
– Kirby
Jan 9 '18 at 14:18
add a comment |
Method based upon tqdm:
tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f168749%2fis-there-a-way-to-see-any-tar-progress-per-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
10 Answers
10
active
oldest
votes
10 Answers
10
active
oldest
votes
active
oldest
votes
active
oldest
votes
I prefer oneliners like this:
tar cf - /folder-with-big-files -P | pv -s $(du -sb /folder-with-big-files | awk '{print $1}') | gzip > big-files.tar.gz
It will have output like this:
4.69GB 0:04:50 [16.3MB/s] [==========================> ] 78% ETA 0:01:21
For OSX (from Kenji's answer)
tar cf - /folder-with-big-files -P | pv -s $(($(du -sk /folder-with-big-files | awk '{print $1}') * 1024)) | gzip > big-files.tar.gz
2
On OSX, du does not take -b argument, needed to fallback to : $((du -sk /folder-with | awk '{print $1}') * 1024))
– ıɾuǝʞ
Nov 29 '13 at 10:14
4
Nice, a one liner. Can you explain it? Or does it just magically work somehow?
– Kissaki
Oct 4 '14 at 18:02
Can you write command to extract tar file like above?
– Krzysztof Szewczyk
Nov 26 '14 at 13:47
2
Ok, I have itpv $FILE.tgz | tar xzf - -C $DEST_DIR
– Krzysztof Szewczyk
Nov 28 '14 at 7:57
1
okay I figured it out thanks to this : stackoverflow.com/a/19372542/4770754 , it's :pv archive.tar.xz | tar xp -J -C ~/location
– tatsu
Mar 8 at 10:19
|
show 8 more comments
I prefer oneliners like this:
tar cf - /folder-with-big-files -P | pv -s $(du -sb /folder-with-big-files | awk '{print $1}') | gzip > big-files.tar.gz
It will have output like this:
4.69GB 0:04:50 [16.3MB/s] [==========================> ] 78% ETA 0:01:21
For OSX (from Kenji's answer)
tar cf - /folder-with-big-files -P | pv -s $(($(du -sk /folder-with-big-files | awk '{print $1}') * 1024)) | gzip > big-files.tar.gz
2
On OSX, du does not take -b argument, needed to fallback to : $((du -sk /folder-with | awk '{print $1}') * 1024))
– ıɾuǝʞ
Nov 29 '13 at 10:14
4
Nice, a one liner. Can you explain it? Or does it just magically work somehow?
– Kissaki
Oct 4 '14 at 18:02
Can you write command to extract tar file like above?
– Krzysztof Szewczyk
Nov 26 '14 at 13:47
2
Ok, I have itpv $FILE.tgz | tar xzf - -C $DEST_DIR
– Krzysztof Szewczyk
Nov 28 '14 at 7:57
1
okay I figured it out thanks to this : stackoverflow.com/a/19372542/4770754 , it's :pv archive.tar.xz | tar xp -J -C ~/location
– tatsu
Mar 8 at 10:19
|
show 8 more comments
I prefer oneliners like this:
tar cf - /folder-with-big-files -P | pv -s $(du -sb /folder-with-big-files | awk '{print $1}') | gzip > big-files.tar.gz
It will have output like this:
4.69GB 0:04:50 [16.3MB/s] [==========================> ] 78% ETA 0:01:21
For OSX (from Kenji's answer)
tar cf - /folder-with-big-files -P | pv -s $(($(du -sk /folder-with-big-files | awk '{print $1}') * 1024)) | gzip > big-files.tar.gz
I prefer oneliners like this:
tar cf - /folder-with-big-files -P | pv -s $(du -sb /folder-with-big-files | awk '{print $1}') | gzip > big-files.tar.gz
It will have output like this:
4.69GB 0:04:50 [16.3MB/s] [==========================> ] 78% ETA 0:01:21
For OSX (from Kenji's answer)
tar cf - /folder-with-big-files -P | pv -s $(($(du -sk /folder-with-big-files | awk '{print $1}') * 1024)) | gzip > big-files.tar.gz
edited Feb 15 at 6:18
answered Oct 25 '13 at 8:15
checksumchecksum
1,074119
1,074119
2
On OSX, du does not take -b argument, needed to fallback to : $((du -sk /folder-with | awk '{print $1}') * 1024))
– ıɾuǝʞ
Nov 29 '13 at 10:14
4
Nice, a one liner. Can you explain it? Or does it just magically work somehow?
– Kissaki
Oct 4 '14 at 18:02
Can you write command to extract tar file like above?
– Krzysztof Szewczyk
Nov 26 '14 at 13:47
2
Ok, I have itpv $FILE.tgz | tar xzf - -C $DEST_DIR
– Krzysztof Szewczyk
Nov 28 '14 at 7:57
1
okay I figured it out thanks to this : stackoverflow.com/a/19372542/4770754 , it's :pv archive.tar.xz | tar xp -J -C ~/location
– tatsu
Mar 8 at 10:19
|
show 8 more comments
2
On OSX, du does not take -b argument, needed to fallback to : $((du -sk /folder-with | awk '{print $1}') * 1024))
– ıɾuǝʞ
Nov 29 '13 at 10:14
4
Nice, a one liner. Can you explain it? Or does it just magically work somehow?
– Kissaki
Oct 4 '14 at 18:02
Can you write command to extract tar file like above?
– Krzysztof Szewczyk
Nov 26 '14 at 13:47
2
Ok, I have itpv $FILE.tgz | tar xzf - -C $DEST_DIR
– Krzysztof Szewczyk
Nov 28 '14 at 7:57
1
okay I figured it out thanks to this : stackoverflow.com/a/19372542/4770754 , it's :pv archive.tar.xz | tar xp -J -C ~/location
– tatsu
Mar 8 at 10:19
2
2
On OSX, du does not take -b argument, needed to fallback to : $((du -sk /folder-with | awk '{print $1}') * 1024))
– ıɾuǝʞ
Nov 29 '13 at 10:14
On OSX, du does not take -b argument, needed to fallback to : $((du -sk /folder-with | awk '{print $1}') * 1024))
– ıɾuǝʞ
Nov 29 '13 at 10:14
4
4
Nice, a one liner. Can you explain it? Or does it just magically work somehow?
– Kissaki
Oct 4 '14 at 18:02
Nice, a one liner. Can you explain it? Or does it just magically work somehow?
– Kissaki
Oct 4 '14 at 18:02
Can you write command to extract tar file like above?
– Krzysztof Szewczyk
Nov 26 '14 at 13:47
Can you write command to extract tar file like above?
– Krzysztof Szewczyk
Nov 26 '14 at 13:47
2
2
Ok, I have it
pv $FILE.tgz | tar xzf - -C $DEST_DIR
– Krzysztof Szewczyk
Nov 28 '14 at 7:57
Ok, I have it
pv $FILE.tgz | tar xzf - -C $DEST_DIR
– Krzysztof Szewczyk
Nov 28 '14 at 7:57
1
1
okay I figured it out thanks to this : stackoverflow.com/a/19372542/4770754 , it's :
pv archive.tar.xz | tar xp -J -C ~/location
– tatsu
Mar 8 at 10:19
okay I figured it out thanks to this : stackoverflow.com/a/19372542/4770754 , it's :
pv archive.tar.xz | tar xp -J -C ~/location
– tatsu
Mar 8 at 10:19
|
show 8 more comments
You can use pv to achieve this. To report the progress correctly, pv
needs to know how much bytes you are throwing at it. So, the first step is to calculate the size (in kbyte). You can also completely drop the progress bar and just let pv
tell you how much bytes it has seen; it would report a 'done that much and that fast'.
% SIZE=`du -sk folder-with-big-files | cut -f 1`
And then:
% tar cvf - folder-with-big-files | pv -p -s ${SIZE}k |
bzip2 -c > big-files.tar.bz2
Cool.pv
doesn't seem to come with Mac OS X, but will try this out once I have a computer with MacPorts on it. Could you explain what you are doing there though? Not quite sure what the first line does exactly.
– Svish
Jul 28 '10 at 12:10
4
first line: fetch info about how many bytes will be handled. second line: use the size from the first line to allow pv to render 'progress'. since you are piping data, pv does not know how many more bytes will come.
– akira
Jul 22 '11 at 10:25
One addition:SIZE=$(($SIZE * 1000 / 1024))
- I don't know whether or not this is a quirk on my particular platform, so I'm not adding it to the answer:du
returns size where 1 kb = 1024 bytes, whilepv
seems to be expecting 1 kb = 1000 bytes. (I'm on Ubuntu 10.04)
– Izkata
Dec 11 '11 at 2:27
2
@lzkata you could always askdu
to use your preferred blocksize, e.g.du -s --block-size=1000
, or just work with plain bytes, e.g. drop thek
's from thedu
andpv
calls. Nevertheless, I would expect both to use1024
unless told otherwise, e.g. the--si
switch ondu
, for example.
– Legolas
Feb 23 '12 at 11:05
1
or just drop the k-stuff and just use plain bytes (du -sb
andpv -s
without any modifier). that should end all the confusion.
– akira
Feb 23 '12 at 11:10
|
show 1 more comment
You can use pv to achieve this. To report the progress correctly, pv
needs to know how much bytes you are throwing at it. So, the first step is to calculate the size (in kbyte). You can also completely drop the progress bar and just let pv
tell you how much bytes it has seen; it would report a 'done that much and that fast'.
% SIZE=`du -sk folder-with-big-files | cut -f 1`
And then:
% tar cvf - folder-with-big-files | pv -p -s ${SIZE}k |
bzip2 -c > big-files.tar.bz2
Cool.pv
doesn't seem to come with Mac OS X, but will try this out once I have a computer with MacPorts on it. Could you explain what you are doing there though? Not quite sure what the first line does exactly.
– Svish
Jul 28 '10 at 12:10
4
first line: fetch info about how many bytes will be handled. second line: use the size from the first line to allow pv to render 'progress'. since you are piping data, pv does not know how many more bytes will come.
– akira
Jul 22 '11 at 10:25
One addition:SIZE=$(($SIZE * 1000 / 1024))
- I don't know whether or not this is a quirk on my particular platform, so I'm not adding it to the answer:du
returns size where 1 kb = 1024 bytes, whilepv
seems to be expecting 1 kb = 1000 bytes. (I'm on Ubuntu 10.04)
– Izkata
Dec 11 '11 at 2:27
2
@lzkata you could always askdu
to use your preferred blocksize, e.g.du -s --block-size=1000
, or just work with plain bytes, e.g. drop thek
's from thedu
andpv
calls. Nevertheless, I would expect both to use1024
unless told otherwise, e.g. the--si
switch ondu
, for example.
– Legolas
Feb 23 '12 at 11:05
1
or just drop the k-stuff and just use plain bytes (du -sb
andpv -s
without any modifier). that should end all the confusion.
– akira
Feb 23 '12 at 11:10
|
show 1 more comment
You can use pv to achieve this. To report the progress correctly, pv
needs to know how much bytes you are throwing at it. So, the first step is to calculate the size (in kbyte). You can also completely drop the progress bar and just let pv
tell you how much bytes it has seen; it would report a 'done that much and that fast'.
% SIZE=`du -sk folder-with-big-files | cut -f 1`
And then:
% tar cvf - folder-with-big-files | pv -p -s ${SIZE}k |
bzip2 -c > big-files.tar.bz2
You can use pv to achieve this. To report the progress correctly, pv
needs to know how much bytes you are throwing at it. So, the first step is to calculate the size (in kbyte). You can also completely drop the progress bar and just let pv
tell you how much bytes it has seen; it would report a 'done that much and that fast'.
% SIZE=`du -sk folder-with-big-files | cut -f 1`
And then:
% tar cvf - folder-with-big-files | pv -p -s ${SIZE}k |
bzip2 -c > big-files.tar.bz2
edited Oct 4 '14 at 20:12
JakeGould
32.2k1098141
32.2k1098141
answered Jul 28 '10 at 12:01
akiraakira
49.3k15113152
49.3k15113152
Cool.pv
doesn't seem to come with Mac OS X, but will try this out once I have a computer with MacPorts on it. Could you explain what you are doing there though? Not quite sure what the first line does exactly.
– Svish
Jul 28 '10 at 12:10
4
first line: fetch info about how many bytes will be handled. second line: use the size from the first line to allow pv to render 'progress'. since you are piping data, pv does not know how many more bytes will come.
– akira
Jul 22 '11 at 10:25
One addition:SIZE=$(($SIZE * 1000 / 1024))
- I don't know whether or not this is a quirk on my particular platform, so I'm not adding it to the answer:du
returns size where 1 kb = 1024 bytes, whilepv
seems to be expecting 1 kb = 1000 bytes. (I'm on Ubuntu 10.04)
– Izkata
Dec 11 '11 at 2:27
2
@lzkata you could always askdu
to use your preferred blocksize, e.g.du -s --block-size=1000
, or just work with plain bytes, e.g. drop thek
's from thedu
andpv
calls. Nevertheless, I would expect both to use1024
unless told otherwise, e.g. the--si
switch ondu
, for example.
– Legolas
Feb 23 '12 at 11:05
1
or just drop the k-stuff and just use plain bytes (du -sb
andpv -s
without any modifier). that should end all the confusion.
– akira
Feb 23 '12 at 11:10
|
show 1 more comment
Cool.pv
doesn't seem to come with Mac OS X, but will try this out once I have a computer with MacPorts on it. Could you explain what you are doing there though? Not quite sure what the first line does exactly.
– Svish
Jul 28 '10 at 12:10
4
first line: fetch info about how many bytes will be handled. second line: use the size from the first line to allow pv to render 'progress'. since you are piping data, pv does not know how many more bytes will come.
– akira
Jul 22 '11 at 10:25
One addition:SIZE=$(($SIZE * 1000 / 1024))
- I don't know whether or not this is a quirk on my particular platform, so I'm not adding it to the answer:du
returns size where 1 kb = 1024 bytes, whilepv
seems to be expecting 1 kb = 1000 bytes. (I'm on Ubuntu 10.04)
– Izkata
Dec 11 '11 at 2:27
2
@lzkata you could always askdu
to use your preferred blocksize, e.g.du -s --block-size=1000
, or just work with plain bytes, e.g. drop thek
's from thedu
andpv
calls. Nevertheless, I would expect both to use1024
unless told otherwise, e.g. the--si
switch ondu
, for example.
– Legolas
Feb 23 '12 at 11:05
1
or just drop the k-stuff and just use plain bytes (du -sb
andpv -s
without any modifier). that should end all the confusion.
– akira
Feb 23 '12 at 11:10
Cool.
pv
doesn't seem to come with Mac OS X, but will try this out once I have a computer with MacPorts on it. Could you explain what you are doing there though? Not quite sure what the first line does exactly.– Svish
Jul 28 '10 at 12:10
Cool.
pv
doesn't seem to come with Mac OS X, but will try this out once I have a computer with MacPorts on it. Could you explain what you are doing there though? Not quite sure what the first line does exactly.– Svish
Jul 28 '10 at 12:10
4
4
first line: fetch info about how many bytes will be handled. second line: use the size from the first line to allow pv to render 'progress'. since you are piping data, pv does not know how many more bytes will come.
– akira
Jul 22 '11 at 10:25
first line: fetch info about how many bytes will be handled. second line: use the size from the first line to allow pv to render 'progress'. since you are piping data, pv does not know how many more bytes will come.
– akira
Jul 22 '11 at 10:25
One addition:
SIZE=$(($SIZE * 1000 / 1024))
- I don't know whether or not this is a quirk on my particular platform, so I'm not adding it to the answer: du
returns size where 1 kb = 1024 bytes, while pv
seems to be expecting 1 kb = 1000 bytes. (I'm on Ubuntu 10.04)– Izkata
Dec 11 '11 at 2:27
One addition:
SIZE=$(($SIZE * 1000 / 1024))
- I don't know whether or not this is a quirk on my particular platform, so I'm not adding it to the answer: du
returns size where 1 kb = 1024 bytes, while pv
seems to be expecting 1 kb = 1000 bytes. (I'm on Ubuntu 10.04)– Izkata
Dec 11 '11 at 2:27
2
2
@lzkata you could always ask
du
to use your preferred blocksize, e.g. du -s --block-size=1000
, or just work with plain bytes, e.g. drop the k
's from the du
and pv
calls. Nevertheless, I would expect both to use 1024
unless told otherwise, e.g. the --si
switch on du
, for example.– Legolas
Feb 23 '12 at 11:05
@lzkata you could always ask
du
to use your preferred blocksize, e.g. du -s --block-size=1000
, or just work with plain bytes, e.g. drop the k
's from the du
and pv
calls. Nevertheless, I would expect both to use 1024
unless told otherwise, e.g. the --si
switch on du
, for example.– Legolas
Feb 23 '12 at 11:05
1
1
or just drop the k-stuff and just use plain bytes (
du -sb
and pv -s
without any modifier). that should end all the confusion.– akira
Feb 23 '12 at 11:10
or just drop the k-stuff and just use plain bytes (
du -sb
and pv -s
without any modifier). that should end all the confusion.– akira
Feb 23 '12 at 11:10
|
show 1 more comment
better progress bar..
apt-get install pv dialog
(pv -n file.tgz | tar xzf - -C target_directory )
2>&1 | dialog --gauge "Extracting file..." 6 50
2
This is works for extraction, but you still need to do one of the more complicated commands for creation (which was the original question). It could still be combined with those; it's just more complicated.
– Daniel H
Aug 9 '14 at 5:05
add a comment |
better progress bar..
apt-get install pv dialog
(pv -n file.tgz | tar xzf - -C target_directory )
2>&1 | dialog --gauge "Extracting file..." 6 50
2
This is works for extraction, but you still need to do one of the more complicated commands for creation (which was the original question). It could still be combined with those; it's just more complicated.
– Daniel H
Aug 9 '14 at 5:05
add a comment |
better progress bar..
apt-get install pv dialog
(pv -n file.tgz | tar xzf - -C target_directory )
2>&1 | dialog --gauge "Extracting file..." 6 50
better progress bar..
apt-get install pv dialog
(pv -n file.tgz | tar xzf - -C target_directory )
2>&1 | dialog --gauge "Extracting file..." 6 50
answered Aug 28 '12 at 8:26
Mr. BlackMr. Black
32737
32737
2
This is works for extraction, but you still need to do one of the more complicated commands for creation (which was the original question). It could still be combined with those; it's just more complicated.
– Daniel H
Aug 9 '14 at 5:05
add a comment |
2
This is works for extraction, but you still need to do one of the more complicated commands for creation (which was the original question). It could still be combined with those; it's just more complicated.
– Daniel H
Aug 9 '14 at 5:05
2
2
This is works for extraction, but you still need to do one of the more complicated commands for creation (which was the original question). It could still be combined with those; it's just more complicated.
– Daniel H
Aug 9 '14 at 5:05
This is works for extraction, but you still need to do one of the more complicated commands for creation (which was the original question). It could still be combined with those; it's just more complicated.
– Daniel H
Aug 9 '14 at 5:05
add a comment |
Check out the --checkpoint
and --checkpoint-action
options in the tar info page (as for my distribution, the description for these options is not contained in the man page → RTFI).
See https://www.gnu.org/software/tar/manual/html_section/tar_26.html
With these (and maybe the functionality to write your own checkpoint command), you can calculate a percentage…
2
This should be the correct answer. Others just explain extra tools (not installed by default, besides) to achieve something similar.
– Carmine Giangregorio
Nov 15 '16 at 14:47
@Sardathrion Maybe because it's GNU-tar
specific.
– phk
Feb 24 '17 at 11:52
add a comment |
Check out the --checkpoint
and --checkpoint-action
options in the tar info page (as for my distribution, the description for these options is not contained in the man page → RTFI).
See https://www.gnu.org/software/tar/manual/html_section/tar_26.html
With these (and maybe the functionality to write your own checkpoint command), you can calculate a percentage…
2
This should be the correct answer. Others just explain extra tools (not installed by default, besides) to achieve something similar.
– Carmine Giangregorio
Nov 15 '16 at 14:47
@Sardathrion Maybe because it's GNU-tar
specific.
– phk
Feb 24 '17 at 11:52
add a comment |
Check out the --checkpoint
and --checkpoint-action
options in the tar info page (as for my distribution, the description for these options is not contained in the man page → RTFI).
See https://www.gnu.org/software/tar/manual/html_section/tar_26.html
With these (and maybe the functionality to write your own checkpoint command), you can calculate a percentage…
Check out the --checkpoint
and --checkpoint-action
options in the tar info page (as for my distribution, the description for these options is not contained in the man page → RTFI).
See https://www.gnu.org/software/tar/manual/html_section/tar_26.html
With these (and maybe the functionality to write your own checkpoint command), you can calculate a percentage…
edited Sep 8 '16 at 0:48
fixer1234
19k144982
19k144982
answered Aug 4 '11 at 20:53
helperhelper
14912
14912
2
This should be the correct answer. Others just explain extra tools (not installed by default, besides) to achieve something similar.
– Carmine Giangregorio
Nov 15 '16 at 14:47
@Sardathrion Maybe because it's GNU-tar
specific.
– phk
Feb 24 '17 at 11:52
add a comment |
2
This should be the correct answer. Others just explain extra tools (not installed by default, besides) to achieve something similar.
– Carmine Giangregorio
Nov 15 '16 at 14:47
@Sardathrion Maybe because it's GNU-tar
specific.
– phk
Feb 24 '17 at 11:52
2
2
This should be the correct answer. Others just explain extra tools (not installed by default, besides) to achieve something similar.
– Carmine Giangregorio
Nov 15 '16 at 14:47
This should be the correct answer. Others just explain extra tools (not installed by default, besides) to achieve something similar.
– Carmine Giangregorio
Nov 15 '16 at 14:47
@Sardathrion Maybe because it's GNU-
tar
specific.– phk
Feb 24 '17 at 11:52
@Sardathrion Maybe because it's GNU-
tar
specific.– phk
Feb 24 '17 at 11:52
add a comment |
Inspired by helper’s answer
Another way is use the native tar
options
FROMSIZE=`du -sk ${FROMPATH} | cut -f 1`;
CHECKPOINT=`echo ${FROMSIZE}/50 | bc`;
echo "Estimated: [==================================================]";
echo -n "Progess: [";
tar -c --record-size=1K --checkpoint="${CHECKPOINT}" --checkpoint-action="ttyout=>" -f - "${FROMPATH}" | bzip2 > "${TOFILE}";
echo "]"
the result is like
Estimated: [==================================================]
Progess: [>>>>>>>>>>>>>>>>>>>>>>>
a complete example here
add a comment |
Inspired by helper’s answer
Another way is use the native tar
options
FROMSIZE=`du -sk ${FROMPATH} | cut -f 1`;
CHECKPOINT=`echo ${FROMSIZE}/50 | bc`;
echo "Estimated: [==================================================]";
echo -n "Progess: [";
tar -c --record-size=1K --checkpoint="${CHECKPOINT}" --checkpoint-action="ttyout=>" -f - "${FROMPATH}" | bzip2 > "${TOFILE}";
echo "]"
the result is like
Estimated: [==================================================]
Progess: [>>>>>>>>>>>>>>>>>>>>>>>
a complete example here
add a comment |
Inspired by helper’s answer
Another way is use the native tar
options
FROMSIZE=`du -sk ${FROMPATH} | cut -f 1`;
CHECKPOINT=`echo ${FROMSIZE}/50 | bc`;
echo "Estimated: [==================================================]";
echo -n "Progess: [";
tar -c --record-size=1K --checkpoint="${CHECKPOINT}" --checkpoint-action="ttyout=>" -f - "${FROMPATH}" | bzip2 > "${TOFILE}";
echo "]"
the result is like
Estimated: [==================================================]
Progess: [>>>>>>>>>>>>>>>>>>>>>>>
a complete example here
Inspired by helper’s answer
Another way is use the native tar
options
FROMSIZE=`du -sk ${FROMPATH} | cut -f 1`;
CHECKPOINT=`echo ${FROMSIZE}/50 | bc`;
echo "Estimated: [==================================================]";
echo -n "Progess: [";
tar -c --record-size=1K --checkpoint="${CHECKPOINT}" --checkpoint-action="ttyout=>" -f - "${FROMPATH}" | bzip2 > "${TOFILE}";
echo "]"
the result is like
Estimated: [==================================================]
Progess: [>>>>>>>>>>>>>>>>>>>>>>>
a complete example here
answered Jul 16 '17 at 0:22
campisanocampisano
9112
9112
add a comment |
add a comment |
Just noticed the comment about MacOS, and while I think the solution from @akira (and pv) is much neater I thought I'd chase a hunch and a quick playaround in my MacOS box with tar and sending it a SIGINFO signal. Funnily enough, it worked :) if you're on a BSD-like system, this should work, but on a Linux box, you might need to send a SIGUSR1, and/or tar
might not work the same way.
The down side is that it will only provide you with an output (on stdout) showing you how far through the current file it is since I'm guessing it has no idea about how big the data stream it's getting is.
So yes, an alternative approach would be to fire up tar and periodically send it SIGINFOs anytime you want to know how far it's gotten. How to do this?
The ad-hoc, manual approach
If you want to be able to check status on an ad-hoc basis, you can hit control-T
(as Brian Swift mentioned) in the relevant window which will send the SIGINFO signal across. One issue with that is it will send it to your entire chain I believe, so if you are doing:
% tar cvf - folder-with-big-files | bzip2 -c > big-files.tar.bz2
You will also see bzip2 report it's status along with tar:
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)
This works nicely if you just want to check if that tar
you're running is stuck, or just slow. You probably don't need to worry too much about formatting issues in this case, since it's only a quick check..
The sort of automated approach
If you know it's going to take a while, but want something like a progress indicator, an alternative would be to fire off your tar process and in another terminal work out it's PID and then throw it into a script that just repeatedly sends a signal over. For example, if you have the following scriptlet (and invoke it as say 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?"
If you invoke it this way, since you're targeting only tar
you'll get an output more like this
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)
...
which I admit, is kinda pretty.
Last but not least - my scripting is kinda rusty, so if anyone wants to go in and clean up/fix/improve the code, go for your life :)
2
If runningtar
on the command line, typingcontrol-T
will send it a SIGINFO. If this was in a script it would be done withkill -INFO pid
– Brian Swift
Apr 23 '12 at 4:58
Completely forgot aboutcontrol-T
, I clearly have gotten used to spamming too many console windows for my own good..
– tanantish
Apr 23 '12 at 20:21
1
why can't I see -SIGINFO when doingkill -l
– Felipe Alvarez
Jun 12 '13 at 2:32
add a comment |
Just noticed the comment about MacOS, and while I think the solution from @akira (and pv) is much neater I thought I'd chase a hunch and a quick playaround in my MacOS box with tar and sending it a SIGINFO signal. Funnily enough, it worked :) if you're on a BSD-like system, this should work, but on a Linux box, you might need to send a SIGUSR1, and/or tar
might not work the same way.
The down side is that it will only provide you with an output (on stdout) showing you how far through the current file it is since I'm guessing it has no idea about how big the data stream it's getting is.
So yes, an alternative approach would be to fire up tar and periodically send it SIGINFOs anytime you want to know how far it's gotten. How to do this?
The ad-hoc, manual approach
If you want to be able to check status on an ad-hoc basis, you can hit control-T
(as Brian Swift mentioned) in the relevant window which will send the SIGINFO signal across. One issue with that is it will send it to your entire chain I believe, so if you are doing:
% tar cvf - folder-with-big-files | bzip2 -c > big-files.tar.bz2
You will also see bzip2 report it's status along with tar:
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)
This works nicely if you just want to check if that tar
you're running is stuck, or just slow. You probably don't need to worry too much about formatting issues in this case, since it's only a quick check..
The sort of automated approach
If you know it's going to take a while, but want something like a progress indicator, an alternative would be to fire off your tar process and in another terminal work out it's PID and then throw it into a script that just repeatedly sends a signal over. For example, if you have the following scriptlet (and invoke it as say 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?"
If you invoke it this way, since you're targeting only tar
you'll get an output more like this
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)
...
which I admit, is kinda pretty.
Last but not least - my scripting is kinda rusty, so if anyone wants to go in and clean up/fix/improve the code, go for your life :)
2
If runningtar
on the command line, typingcontrol-T
will send it a SIGINFO. If this was in a script it would be done withkill -INFO pid
– Brian Swift
Apr 23 '12 at 4:58
Completely forgot aboutcontrol-T
, I clearly have gotten used to spamming too many console windows for my own good..
– tanantish
Apr 23 '12 at 20:21
1
why can't I see -SIGINFO when doingkill -l
– Felipe Alvarez
Jun 12 '13 at 2:32
add a comment |
Just noticed the comment about MacOS, and while I think the solution from @akira (and pv) is much neater I thought I'd chase a hunch and a quick playaround in my MacOS box with tar and sending it a SIGINFO signal. Funnily enough, it worked :) if you're on a BSD-like system, this should work, but on a Linux box, you might need to send a SIGUSR1, and/or tar
might not work the same way.
The down side is that it will only provide you with an output (on stdout) showing you how far through the current file it is since I'm guessing it has no idea about how big the data stream it's getting is.
So yes, an alternative approach would be to fire up tar and periodically send it SIGINFOs anytime you want to know how far it's gotten. How to do this?
The ad-hoc, manual approach
If you want to be able to check status on an ad-hoc basis, you can hit control-T
(as Brian Swift mentioned) in the relevant window which will send the SIGINFO signal across. One issue with that is it will send it to your entire chain I believe, so if you are doing:
% tar cvf - folder-with-big-files | bzip2 -c > big-files.tar.bz2
You will also see bzip2 report it's status along with tar:
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)
This works nicely if you just want to check if that tar
you're running is stuck, or just slow. You probably don't need to worry too much about formatting issues in this case, since it's only a quick check..
The sort of automated approach
If you know it's going to take a while, but want something like a progress indicator, an alternative would be to fire off your tar process and in another terminal work out it's PID and then throw it into a script that just repeatedly sends a signal over. For example, if you have the following scriptlet (and invoke it as say 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?"
If you invoke it this way, since you're targeting only tar
you'll get an output more like this
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)
...
which I admit, is kinda pretty.
Last but not least - my scripting is kinda rusty, so if anyone wants to go in and clean up/fix/improve the code, go for your life :)
Just noticed the comment about MacOS, and while I think the solution from @akira (and pv) is much neater I thought I'd chase a hunch and a quick playaround in my MacOS box with tar and sending it a SIGINFO signal. Funnily enough, it worked :) if you're on a BSD-like system, this should work, but on a Linux box, you might need to send a SIGUSR1, and/or tar
might not work the same way.
The down side is that it will only provide you with an output (on stdout) showing you how far through the current file it is since I'm guessing it has no idea about how big the data stream it's getting is.
So yes, an alternative approach would be to fire up tar and periodically send it SIGINFOs anytime you want to know how far it's gotten. How to do this?
The ad-hoc, manual approach
If you want to be able to check status on an ad-hoc basis, you can hit control-T
(as Brian Swift mentioned) in the relevant window which will send the SIGINFO signal across. One issue with that is it will send it to your entire chain I believe, so if you are doing:
% tar cvf - folder-with-big-files | bzip2 -c > big-files.tar.bz2
You will also see bzip2 report it's status along with tar:
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)
This works nicely if you just want to check if that tar
you're running is stuck, or just slow. You probably don't need to worry too much about formatting issues in this case, since it's only a quick check..
The sort of automated approach
If you know it's going to take a while, but want something like a progress indicator, an alternative would be to fire off your tar process and in another terminal work out it's PID and then throw it into a script that just repeatedly sends a signal over. For example, if you have the following scriptlet (and invoke it as say 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?"
If you invoke it this way, since you're targeting only tar
you'll get an output more like this
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)
...
which I admit, is kinda pretty.
Last but not least - my scripting is kinda rusty, so if anyone wants to go in and clean up/fix/improve the code, go for your life :)
edited Apr 24 '12 at 11:16
answered Apr 21 '12 at 20:44
tanantishtanantish
1,024712
1,024712
2
If runningtar
on the command line, typingcontrol-T
will send it a SIGINFO. If this was in a script it would be done withkill -INFO pid
– Brian Swift
Apr 23 '12 at 4:58
Completely forgot aboutcontrol-T
, I clearly have gotten used to spamming too many console windows for my own good..
– tanantish
Apr 23 '12 at 20:21
1
why can't I see -SIGINFO when doingkill -l
– Felipe Alvarez
Jun 12 '13 at 2:32
add a comment |
2
If runningtar
on the command line, typingcontrol-T
will send it a SIGINFO. If this was in a script it would be done withkill -INFO pid
– Brian Swift
Apr 23 '12 at 4:58
Completely forgot aboutcontrol-T
, I clearly have gotten used to spamming too many console windows for my own good..
– tanantish
Apr 23 '12 at 20:21
1
why can't I see -SIGINFO when doingkill -l
– Felipe Alvarez
Jun 12 '13 at 2:32
2
2
If running
tar
on the command line, typing control-T
will send it a SIGINFO. If this was in a script it would be done with kill -INFO pid
– Brian Swift
Apr 23 '12 at 4:58
If running
tar
on the command line, typing control-T
will send it a SIGINFO. If this was in a script it would be done with kill -INFO pid
– Brian Swift
Apr 23 '12 at 4:58
Completely forgot about
control-T
, I clearly have gotten used to spamming too many console windows for my own good..– tanantish
Apr 23 '12 at 20:21
Completely forgot about
control-T
, I clearly have gotten used to spamming too many console windows for my own good..– tanantish
Apr 23 '12 at 20:21
1
1
why can't I see -SIGINFO when doing
kill -l
– Felipe Alvarez
Jun 12 '13 at 2:32
why can't I see -SIGINFO when doing
kill -l
– Felipe Alvarez
Jun 12 '13 at 2:32
add a comment |
Inspired by Noah Spurrier’s answer
function tar {
local bf so
so=${*: -1}
case $(file "$so" | awk '{print$2}') in
XZ) bf=$(xz -lv "$so" |
perl -MPOSIX -ane '$.==11 && print ceil $F[5]/50688') ;;
gzip) bf=$(gzip -l "$so" |
perl -MPOSIX -ane '$.==2 && print ceil $F[1]/50688') ;;
directory) bf=$(find "$so" -type f | xargs du -B512 --apparent-size |
perl -MPOSIX -ane '$bk += $F[0]+1; END {print ceil $bk/100}') ;;
esac
command tar "$@" --blocking-factor=$bf
--checkpoint-action='ttyout=%u%r' --checkpoint=1
}
Source
17
A little context and explanation maybe?
– Kissaki
Oct 4 '14 at 18:03
add a comment |
Inspired by Noah Spurrier’s answer
function tar {
local bf so
so=${*: -1}
case $(file "$so" | awk '{print$2}') in
XZ) bf=$(xz -lv "$so" |
perl -MPOSIX -ane '$.==11 && print ceil $F[5]/50688') ;;
gzip) bf=$(gzip -l "$so" |
perl -MPOSIX -ane '$.==2 && print ceil $F[1]/50688') ;;
directory) bf=$(find "$so" -type f | xargs du -B512 --apparent-size |
perl -MPOSIX -ane '$bk += $F[0]+1; END {print ceil $bk/100}') ;;
esac
command tar "$@" --blocking-factor=$bf
--checkpoint-action='ttyout=%u%r' --checkpoint=1
}
Source
17
A little context and explanation maybe?
– Kissaki
Oct 4 '14 at 18:03
add a comment |
Inspired by Noah Spurrier’s answer
function tar {
local bf so
so=${*: -1}
case $(file "$so" | awk '{print$2}') in
XZ) bf=$(xz -lv "$so" |
perl -MPOSIX -ane '$.==11 && print ceil $F[5]/50688') ;;
gzip) bf=$(gzip -l "$so" |
perl -MPOSIX -ane '$.==2 && print ceil $F[1]/50688') ;;
directory) bf=$(find "$so" -type f | xargs du -B512 --apparent-size |
perl -MPOSIX -ane '$bk += $F[0]+1; END {print ceil $bk/100}') ;;
esac
command tar "$@" --blocking-factor=$bf
--checkpoint-action='ttyout=%u%r' --checkpoint=1
}
Source
Inspired by Noah Spurrier’s answer
function tar {
local bf so
so=${*: -1}
case $(file "$so" | awk '{print$2}') in
XZ) bf=$(xz -lv "$so" |
perl -MPOSIX -ane '$.==11 && print ceil $F[5]/50688') ;;
gzip) bf=$(gzip -l "$so" |
perl -MPOSIX -ane '$.==2 && print ceil $F[1]/50688') ;;
directory) bf=$(find "$so" -type f | xargs du -B512 --apparent-size |
perl -MPOSIX -ane '$bk += $F[0]+1; END {print ceil $bk/100}') ;;
esac
command tar "$@" --blocking-factor=$bf
--checkpoint-action='ttyout=%u%r' --checkpoint=1
}
Source
edited May 23 '17 at 12:41
Community♦
1
1
answered Apr 18 '12 at 1:00
Steven PennySteven Penny
1
1
17
A little context and explanation maybe?
– Kissaki
Oct 4 '14 at 18:03
add a comment |
17
A little context and explanation maybe?
– Kissaki
Oct 4 '14 at 18:03
17
17
A little context and explanation maybe?
– Kissaki
Oct 4 '14 at 18:03
A little context and explanation maybe?
– Kissaki
Oct 4 '14 at 18:03
add a comment |
Using only tar
tar
has the option (since v1.12) to print status information on signals using --totals=$SIGNO
, e.g.:
tar --totals=USR1 -czf output.tar input.file
Total bytes written: 6005319680 (5.6GiB, 23MiB/s)
The Total bytes written: [...]
information gets printed on every USR1 signal, e.g.:
pkill -SIGUSR1 tar
Source:
- gnu.org - GNU tar - 3.7 Checking tar progress
- gnu.org - tar - NEWS
add a comment |
Using only tar
tar
has the option (since v1.12) to print status information on signals using --totals=$SIGNO
, e.g.:
tar --totals=USR1 -czf output.tar input.file
Total bytes written: 6005319680 (5.6GiB, 23MiB/s)
The Total bytes written: [...]
information gets printed on every USR1 signal, e.g.:
pkill -SIGUSR1 tar
Source:
- gnu.org - GNU tar - 3.7 Checking tar progress
- gnu.org - tar - NEWS
add a comment |
Using only tar
tar
has the option (since v1.12) to print status information on signals using --totals=$SIGNO
, e.g.:
tar --totals=USR1 -czf output.tar input.file
Total bytes written: 6005319680 (5.6GiB, 23MiB/s)
The Total bytes written: [...]
information gets printed on every USR1 signal, e.g.:
pkill -SIGUSR1 tar
Source:
- gnu.org - GNU tar - 3.7 Checking tar progress
- gnu.org - tar - NEWS
Using only tar
tar
has the option (since v1.12) to print status information on signals using --totals=$SIGNO
, e.g.:
tar --totals=USR1 -czf output.tar input.file
Total bytes written: 6005319680 (5.6GiB, 23MiB/s)
The Total bytes written: [...]
information gets printed on every USR1 signal, e.g.:
pkill -SIGUSR1 tar
Source:
- gnu.org - GNU tar - 3.7 Checking tar progress
- gnu.org - tar - NEWS
answered Jun 15 '18 at 5:03
MurmelMurmel
385310
385310
add a comment |
add a comment |
If you known the file number instead of total size of all of them:
an alternative (less accurate but suitable) is to use the -l option and send in the unix pipe the filenames instead of data content.
Let's have 12345 files into mydir, command is:
[myhost@myuser mydir]$ tar cfvz ~/mytarfile.tgz .|pv -s 12345 -l > /dev/null
you can know such value in advance (because of your use case) or use some command like find+wc to discover it:
[myhost@myuser mydir]$ find | wc -l
12345
So, why not put this command into sub-command? =)
– Kirby
Jan 9 '18 at 14:12
tar cfvz ~/mytarfile.tgz . | pv -s $(find . | wc -l) -l > /dev/null
. Does it work for you?
– Kirby
Jan 9 '18 at 14:18
add a comment |
If you known the file number instead of total size of all of them:
an alternative (less accurate but suitable) is to use the -l option and send in the unix pipe the filenames instead of data content.
Let's have 12345 files into mydir, command is:
[myhost@myuser mydir]$ tar cfvz ~/mytarfile.tgz .|pv -s 12345 -l > /dev/null
you can know such value in advance (because of your use case) or use some command like find+wc to discover it:
[myhost@myuser mydir]$ find | wc -l
12345
So, why not put this command into sub-command? =)
– Kirby
Jan 9 '18 at 14:12
tar cfvz ~/mytarfile.tgz . | pv -s $(find . | wc -l) -l > /dev/null
. Does it work for you?
– Kirby
Jan 9 '18 at 14:18
add a comment |
If you known the file number instead of total size of all of them:
an alternative (less accurate but suitable) is to use the -l option and send in the unix pipe the filenames instead of data content.
Let's have 12345 files into mydir, command is:
[myhost@myuser mydir]$ tar cfvz ~/mytarfile.tgz .|pv -s 12345 -l > /dev/null
you can know such value in advance (because of your use case) or use some command like find+wc to discover it:
[myhost@myuser mydir]$ find | wc -l
12345
If you known the file number instead of total size of all of them:
an alternative (less accurate but suitable) is to use the -l option and send in the unix pipe the filenames instead of data content.
Let's have 12345 files into mydir, command is:
[myhost@myuser mydir]$ tar cfvz ~/mytarfile.tgz .|pv -s 12345 -l > /dev/null
you can know such value in advance (because of your use case) or use some command like find+wc to discover it:
[myhost@myuser mydir]$ find | wc -l
12345
answered Sep 15 '17 at 12:38
bzimagebzimage
363
363
So, why not put this command into sub-command? =)
– Kirby
Jan 9 '18 at 14:12
tar cfvz ~/mytarfile.tgz . | pv -s $(find . | wc -l) -l > /dev/null
. Does it work for you?
– Kirby
Jan 9 '18 at 14:18
add a comment |
So, why not put this command into sub-command? =)
– Kirby
Jan 9 '18 at 14:12
tar cfvz ~/mytarfile.tgz . | pv -s $(find . | wc -l) -l > /dev/null
. Does it work for you?
– Kirby
Jan 9 '18 at 14:18
So, why not put this command into sub-command? =)
– Kirby
Jan 9 '18 at 14:12
So, why not put this command into sub-command? =)
– Kirby
Jan 9 '18 at 14:12
tar cfvz ~/mytarfile.tgz . | pv -s $(find . | wc -l) -l > /dev/null
. Does it work for you?– Kirby
Jan 9 '18 at 14:18
tar cfvz ~/mytarfile.tgz . | pv -s $(find . | wc -l) -l > /dev/null
. Does it work for you?– Kirby
Jan 9 '18 at 14:18
add a comment |
Method based upon tqdm:
tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null
add a comment |
Method based upon tqdm:
tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null
add a comment |
Method based upon tqdm:
tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null
Method based upon tqdm:
tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null
edited Apr 27 '18 at 6:51
answered Apr 27 '18 at 6:44
J_ZarJ_Zar
1012
1012
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f168749%2fis-there-a-way-to-see-any-tar-progress-per-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown