Re: decompress any compressed type

[Bill Denney]

On Thu, 19 Oct 2006, John W. Eaton wrote:

> On 17-Oct-2006, Bill Denney wrote:
>
> Bill Denney wrote:
> > scripts/ChangeLog:
> >
> > 2006-10-17  Bill Denney  <address@hidden>
> >    * miscellaneous/decompress.m: new function, decompress any file
> > based on its extension
>
> OK, I would accept this function but I have a few comments.
>
> I'm not sure that decompress is the best name since I think of as just
> the compress part, and this function also handles extracting files
> from archives, not just uncompressing them.  Maybe we could call it
> "unpack", though that could also be confusing given the meaning of
> "pack" in Matlab.

While decompress does have a different meaning than the complete 
function, to me, unpack strikes me as the opposite of pack which makes 
me think odd things would happen (i.e. increase the amount of memory 
garbage, or spring a memory leak).  That said, there is almost no chance 
of mathworks making an unpack command.

> |     switch lower(ext)
> |       case {".gz" ".Z"}
> |       files = gunzip (file, directory);
>
> I don't think we have a gunzip (or gzip) function yet.

OK, well it shouldn't be hard to write.

> Now that we have urlwrite, we should be able to fix unzip and write
> a version of gunzip to do things like
>
>    url = "http://some.where.org/some-files.zip";;
>    file_list = unzip (url, 'some-files')
>
> or
>
>  url = "http://www.octave.org/octave-2.1.73.tar.gz";;
>  gunzip (url, "outputdir");
>
> which is needed for Matlab compatibility.

Because this functionality is needed and the other similarities between 
these, it seems to me that it may be better to consolidate the features 
of the decompression/extraction codes into one function.  What would you 
think about that?

> Matlab also searches for files in the MATLABPATH, but I don't think it
> is necessary for Octave to do this.
>
> It would also be nice to have the bunzip2 function.  There would be
> very few differences between gunzip and bunzip2, so they could
> probably be based on a common core funtion.  Likewise for gzip and
> bzip2.

Bill

--
"impotence kills" -- Jim Greenlee