Compress, Gzip, Bzip, Bzip2 are not for archiving multiple files. They only compress single file. For archiving they are usually used with TAR. The problem with TAR is that it has no index table. It's only good if you're planning to restore the whole thing. If you're expecting that you ever need to restore only limited number of selected files, forget about TAR. To get the last file from tar.gz
or tar.bz2
archive, you have to decompress and process all of it. In the case of zip, rar or 7-zip, it'll go to the index table, skip to relevant position of the archive and only process relevant files.
Ok, TAR's out, so that leaves you with ZIP, RAR and 7-ZIP. Of these three, ZIP is the most proliferated, most anything supports it, many applications have built-in support. And it's fast. On the other hand 7-ZIP is also portable, the library is LGPL, and has compression rates much better then other two, comes as a cost of being more CPU consuming. RAR is real loser there, neither great compression, nor really portable, nor fast.
EDIT: seems that the best option would be 7-ZIP, but with bzip2 compression method. This way you won't have the disadvantages of TAR, but you'll can still take advantage of bzip2 multi-core support. See this article.
Best Answer
I think you'll want to use a
case
statement to choose how to unpack the input archive based on the filename (or perhaps usefile
to base it on the content instead). Unpack the input archive to a temporary directory, piping stdout/stdin to /dev/null or a file. Then runzip
on the contents of the temporary directory, saving to a filename provided on the commandline. Remove the temporary directory.Something like this (UNTESTED):
You'll need to determine what errors you get from tar, etc when an achive is "encrypted", and update the error messages appropriately to match what you're after. But this should give you a reasonable starting point.