gzip-like CLI wrapper for p7zip

[Juergen Lock]

In article <20051019102706.GA28521 at aragorn> you write:
>On Tue, Oct 18, 2005 at 10:05:44PM +0200, Juergen Lock wrote:
>> 
>> Well I could add it to the port (see below), but I think the need for
>> tempfiles is unfortunate because it can cause problems like /tmp
>> filling up.
>
>I'm aware of this.  Unfortunately, p7zip doesn't seem to support streaming.
>Try the following command:
>
>  $ echo foo | 7z a dummy -si -so > /dev/null
>
>  (see http://bugs.debian.org/323932 for more details on this)
>
>I don't think the changes are trivial.  Most likely the algorithm requires
>random access, and with my very reduced knowledge in compression techniques or
>p7zip internals, this isn't something I can fix.
>
Well, even if it does, one could always compress fixed-size chunks of
data sequentially.

>> Maybe the 7z lib that cloop uses [1] [2] could be used
>> for a `real' tempfile-less p7zip?
>> [...]
>> [1]	http://advancemame.sourceforge.net/comp-readme.html
>
>It reads:
>
>"Recompress ZIP, GZ, PNG and MNG files using the Deflate 7-Zip implementation."
>
>I don't think this means it supports 7z format.  Most likely it just means it
>took the deflate algorithm code (for gzip, etc) from the 7-zip program (the
>Windows version, which is also LGPL).
>
 Nono, it is indeed 7z (the algo is called LZMA afaik), it is used by
cloop to get better compression than it had previosly (using gzip/bzip2
libs.)

>> (I dont know the 7z file format,
>> maybe a new format has to be created in order to require no seeking,
>> meaning the extension would have to be changed as well. (like gzip
>> had to do with the zip format.)  so maybe we shouldn't standardize
>> on a p7zip command just yet...)
>
>Sorry, I don't know the 7z format either.  However, much like other compression
>formats, it is versioned:
>
>  rmh at aragorn:/tmp$ echo foo | p7zip | file -
>  /dev/stdin: 7z archive data, version 0.2
>
>I don't think there's a problem with standarising on a p7zip command.  Streaming
>is IMHO an essential capability in Un*x-style compressors.  I think it's better
>to emulate it poorly via /tmp hacks, than not having it at all.  For example,
>tar expects compressor programs to support streaming, so if we want to patch it
>to do something like this:
>
>  $ tar -cIf foo.tar.7z bar
>
>we'll need that.  (In fact, this is what I had in mind when writing this
>script).
>
>In case p7zip supports streaming properly later on (either by bumping the format
>version to 0.3 or not), we can get rid of the script, or modify it to something
>that just provides a gzip-like CLI interface that tar would work with.
>
 Well, i dont know if the 7z maintainers are interested in supporting
streaming themselves, it could well happen they bump their version
for other reasons, which means p7zip's version numbering would have
to be orthogonal to theirs...

>(please note, in the above example I'm referring to gnu tar.  I don't know which
>tar implementation is used in FreeBSD, but the same would apply, I think)
>
 Actually bsdtar calls the compression libraries itself (libz and
libbz2), so best would in fact be to turn p7zip into a library too,
but _that_ could still be done later.

>> Index: files/p7zip
>> @@ -0,0 +1,74 @@
>> +#!/bin/sh
>> +# gzip-like CLI wrapper for p7zip
>> +set -e
>
>Btw, I would verify that the script works on FreeBSD.  In particular, I'd check
>the `mktemp' and `which' commands are present and work the same way.  As for
>shell, it needs bourne.  I don't recall using any bashisms but I'm not 1:1 sure.

 Yes I had to adapt the script slightly, as you can see...

	Juergen