64

A fixed-length progress bar, a file or byte count, or better yet a timer showing the estimated time remaining would be ideal.

zip's standard behavior seems to be to print a line for every file processed, but I don't want that information overload when I zip thousands of files. I want a guesstimate how long it's going to take.

I tried the -q (--quiet) option in combination with -dg (--display-globaldots) but that just floods stdout with multiple lines of dots and gives no useful indication.

I also tried -qdgds 10m as mentioned in the man page, but got the same result.

I then tried -db (--display-bytes) and -dc (--display-counts) but there doesn't seem to be a global option, so it again prints it for every filename.

Lastly, I tried it together with -q like -qdbdc, but that just outputs nothing.

Funnily enough, I found a man page on the info-zip site that mentions a -de (--display-est-to-go) option which should "Display an estimate of the time to finish the archiving operation."

That sounds exactly like what I want, but the problem is that my version of zip does not have that feature. I'm using Ubuntu 14.04.1 64bit, bash-4.3.30(1) and zip-3.00. According to Wikipedia, this is zip's latest stable release.

There are unreleased beta versions on the info-zip sourceforge page, but I'd rather not entrust my data to a beta release.

Improve this question
3
  • Log the output to a file and use it to provide high level info with tee. Before starting zip, make a total count of the files (with ls or find -type f) and while it is zipping, read the log file for the number of lines of processed files it already has (with grep for the right lines to look at, and wc -l for the lines count), so your high level info will show something like "234/76438 files processed";
    – Aquarius Power
    Commented Apr 27, 2015 at 1:35
  • you can work the timing by considering the total files size and checking the size of the ones that were already processed; but... even files with the same size take different time to be processed so it will always be a wild guess...
    – Aquarius Power
    Commented Apr 27, 2015 at 1:40
  • I don't know if you can use stdin when making ZIP files, but if gzip is okay, you can do something like pv /path/to/file | gzip > /path/to/file.gz
    – DopeGhoti
    Commented Jul 28, 2015 at 23:51

8 Answers 8

Reset to default
31

If you're ok with using 7z:

7z a output.zip folder/

This will give you a progress bar like this:

Open archive: test.zip
--
Path = test.zip
Type = zip
Physical Size = 232039663

Scanning the drive:
3 folders, 2401 files, 238122225 bytes (228 MiB)

Updating archive: test.zip

Items to compress: 2404

 16% 279 U folder/file.txt
Improve this answer
2
  • 2
    When I finally made zip's -rqdgds option work, it showed each dot on the next line, which is useless if you need more than a few dozen dots. So 7z was indeed the simplest way to go.
    – Rodrigo
    Commented Dec 21, 2020 at 22:47
  • @Rodrigo sometimes the best answer is to just use a different tool.
    – qwr
    Commented Dec 22, 2020 at 9:34
25

zip can compress data to standard output. Hence, you can combine it with other tools like pv:

zip -qr - [folder] | pv -bep -s $(du -bs [folder] | awk '{print $1}') > [file.zip]

Remove one of the -bep options as your convenience.

Improve this answer
1
  • Thanks for this! I do this on my mac (brew install pv, brew install coreutils, and replace du with gdu).
    – Jeff
    Commented Oct 26, 2017 at 13:46
5

I have successfully used the following:

zip -r [target_zip] [folder_to_zip] 2>&1 | 
pv -lep -s $(ls -Rl1 [folder_to_zip] | egrep -c '^[-/]') > /dev/null

And this is explained below:

zip -r [target_zip] [folder_to_zip] 2>&1 |

zip recursively into [target_zip] file the [folder_to_zip] redirecting stderr to stdout. Note that stderr will contain one line for each file and directory being processed.

pv -lep -s $(ls -Ral1 [folder_to_zip] | egrep -c '^[-/]') > /dev/null

pipe into pv the lines with the filenames as they are being output from zip. pv is operated in line mode (counting progress based on lines and size is also in number of lines to expect – see PV man page -l option).

The total size of lines to expect is gathered by recursively listing (ls) the [folder_to_zip] and counting the lines starting with '-' or 'd', i.e., all the files and directories (remember directories are listed starting with '/' ).

The above provides accurate percentage of completion as the 100% is reached when all files and directories have been processed.

The problem with the answer of pedroapero is that progress is calculated on number of bytes processed (compressed) over the total number of bytes to process (uncompressed). As a result the process will complete at around 30% (depending on the compression rate).

Improve this answer
2
  • Thanks for your additional reply. That's correct, I guess it all depends of file size distribution, and content entropy.
    – pedroapero
    Commented Sep 14, 2020 at 16:57
  • Great explanations!
    – Saddle Point
    Commented Jan 29, 2021 at 15:08
3

Use (-q)[--quiet] option , like zip -q .... see man zip for more https://linux.die.net/man/1/zip

Improve this answer
1
  • 4
    Does that show the progress?
    – X Tian
    Commented Mar 19, 2021 at 18:04
1

You can add -qq flag to the command. This worked for me.
Example:

zip -r -qq out_chairs.zip out_chairs/
Improve this answer
1
  • 1
    Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Feb 9, 2023 at 20:35
0

I would use grep expression

egrep -c '^([-d][rwx-]{9})'

At least for me on Ubuntu, no directory starts with "/" but rather with "d" (sure you could use [-d] only, but I was not sure about the recursive output of 'ls'.

drwxr-xr-x  3 user user 4096 apr 14  2015 gems

Also note we are not counting in hidden files here (or better said, the first instance of the command Lefteris wrote). And due to "." and ".." I would say the counts will be off (the more complex the directory tree, the worse estimate for the pv) if we use switch "-a". So that could also be somehow taken care of in the grep or perhaps in ls depending on your system.

Improve this answer
2
  • did you answer the wrong question?
    – qwr
    Commented Apr 12, 2022 at 8:09
  • You are probably right. I've reiterated on one of the answers here. So I better find the exact usage of the zip I did and edit my post. Thanks.
    – Valh4ll4
    Commented May 2, 2022 at 23:29
0

I would better use:

cat INPUTFILE.img | pv -bep -s $(du -bs INPUTFILE.img | awk '{print $1}') | zip -q > OUTPUTFILE.zip

In that case you see real percentage of data through "PV" The only trouble now is file name, which can be solved:

echo -e "@ -\n@=NEWNAME.img" | zipnote -w OUTPUTFILE.zip

Or both commands in one line:

cat INPUTFILE.img | pv -bep -s $(du -bs INPUTFILE.img | awk '{print $1}') | zip -q > OUTPUTFILE.zip ; echo -e "@ -\n@=NEWNAME.img" | zipnote -w OUTPUTFILE.zip
Improve this answer
0

I read up on the zip man page on my MacOS (man zip), and read this which worked great for me - quoting from the man page output:

-dg
--display-globaldots
    Display progress dots for the archive instead of for each file.  The command

        zip -qdgds 10m

    will turn off most output except dots every 10 MB.

For example, this is the command I used to zip up the folders in the working directory:

for dir in */ ; do
   echo "Zipping up $dir ..."
   zip -rqdgds 50m ${dir%/}.zip ${dir} -x .git/**\*  -x .zip/**
done
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .