Is there a way to see any tar progress per file?












114















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.










share|improve this question





























    114















    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.










    share|improve this question



























      114












      114








      114


      63






      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.










      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Oct 19 '12 at 5:21









      Journeyman Geek

      113k44217371




      113k44217371










      asked Jul 28 '10 at 11:51









      SvishSvish

      16.6k54109168




      16.6k54109168






















          10 Answers
          10






          active

          oldest

          votes


















          87














          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





          share|improve this answer





















          • 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 it pv $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



















          73














          You can use pv to achieve this. To report the progress correctly, pvneeds 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





          share|improve this answer


























          • 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, while pv 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 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





            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



















          22














          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


          enter image description here






          share|improve this answer



















          • 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



















          14














          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…






          share|improve this answer





















          • 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



















          7














          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






          share|improve this answer































            3














            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 :)






            share|improve this answer





















            • 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











            • 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





              why can't I see -SIGINFO when doing kill -l

              – Felipe Alvarez
              Jun 12 '13 at 2:32



















            2














            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






            share|improve this answer





















            • 17





              A little context and explanation maybe?

              – Kissaki
              Oct 4 '14 at 18:03



















            2














            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






            share|improve this answer































              1














              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





              share|improve this answer
























              • 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





















              0














              Method based upon tqdm:



              tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null





              share|improve this answer


























                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
                });


                }
                });














                draft saved

                draft discarded


















                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









                87














                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





                share|improve this answer





















                • 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 it pv $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
















                87














                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





                share|improve this answer





















                • 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 it pv $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














                87












                87








                87







                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





                share|improve this answer















                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






                share|improve this answer














                share|improve this answer



                share|improve this answer








                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 it pv $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





                  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 it pv $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













                73














                You can use pv to achieve this. To report the progress correctly, pvneeds 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





                share|improve this answer


























                • 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, while pv 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 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





                  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
















                73














                You can use pv to achieve this. To report the progress correctly, pvneeds 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





                share|improve this answer


























                • 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, while pv 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 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





                  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














                73












                73








                73







                You can use pv to achieve this. To report the progress correctly, pvneeds 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





                share|improve this answer















                You can use pv to achieve this. To report the progress correctly, pvneeds 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






                share|improve this answer














                share|improve this answer



                share|improve this answer








                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, while pv 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 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





                  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



















                • 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, while pv 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 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





                  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

















                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











                22














                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


                enter image description here






                share|improve this answer



















                • 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
















                22














                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


                enter image description here






                share|improve this answer



















                • 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














                22












                22








                22







                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


                enter image description here






                share|improve this answer













                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


                enter image description here







                share|improve this answer












                share|improve this answer



                share|improve this answer










                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














                • 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











                14














                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…






                share|improve this answer





















                • 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
















                14














                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…






                share|improve this answer





















                • 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














                14












                14








                14







                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…






                share|improve this answer















                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…







                share|improve this answer














                share|improve this answer



                share|improve this answer








                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














                • 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











                7














                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






                share|improve this answer




























                  7














                  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






                  share|improve this answer


























                    7












                    7








                    7







                    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






                    share|improve this answer













                    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







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Jul 16 '17 at 0:22









                    campisanocampisano

                    9112




                    9112























                        3














                        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 :)






                        share|improve this answer





















                        • 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











                        • 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





                          why can't I see -SIGINFO when doing kill -l

                          – Felipe Alvarez
                          Jun 12 '13 at 2:32
















                        3














                        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 :)






                        share|improve this answer





















                        • 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











                        • 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





                          why can't I see -SIGINFO when doing kill -l

                          – Felipe Alvarez
                          Jun 12 '13 at 2:32














                        3












                        3








                        3







                        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 :)






                        share|improve this answer















                        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 :)







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Apr 24 '12 at 11:16

























                        answered Apr 21 '12 at 20:44









                        tanantishtanantish

                        1,024712




                        1,024712








                        • 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











                        • 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





                          why can't I see -SIGINFO when doing kill -l

                          – Felipe Alvarez
                          Jun 12 '13 at 2:32














                        • 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











                        • 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





                          why can't I see -SIGINFO when doing kill -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











                        2














                        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






                        share|improve this answer





















                        • 17





                          A little context and explanation maybe?

                          – Kissaki
                          Oct 4 '14 at 18:03
















                        2














                        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






                        share|improve this answer





















                        • 17





                          A little context and explanation maybe?

                          – Kissaki
                          Oct 4 '14 at 18:03














                        2












                        2








                        2







                        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






                        share|improve this answer















                        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







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        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














                        • 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











                        2














                        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






                        share|improve this answer




























                          2














                          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






                          share|improve this answer


























                            2












                            2








                            2







                            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






                            share|improve this answer













                            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







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Jun 15 '18 at 5:03









                            MurmelMurmel

                            385310




                            385310























                                1














                                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





                                share|improve this answer
























                                • 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


















                                1














                                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





                                share|improve this answer
























                                • 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
















                                1












                                1








                                1







                                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





                                share|improve this answer













                                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






                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                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





















                                • 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













                                0














                                Method based upon tqdm:



                                tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null





                                share|improve this answer






























                                  0














                                  Method based upon tqdm:



                                  tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null





                                  share|improve this answer




























                                    0












                                    0








                                    0







                                    Method based upon tqdm:



                                    tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null





                                    share|improve this answer















                                    Method based upon tqdm:



                                    tar -v -xf tarfile.tar -C TARGET_DIR | tqdm --total $(tar -tvf tarfile.tar | wc -l) > /dev/null






                                    share|improve this answer














                                    share|improve this answer



                                    share|improve this answer








                                    edited Apr 27 '18 at 6:51

























                                    answered Apr 27 '18 at 6:44









                                    J_ZarJ_Zar

                                    1012




                                    1012






























                                        draft saved

                                        draft discarded




















































                                        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.




                                        draft saved


                                        draft discarded














                                        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





















































                                        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







                                        Popular posts from this blog

                                        flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                                        Mangá

                                        Eduardo VII do Reino Unido