[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: untar.m on Solaris with non-GNU tar

From: John W. Eaton
Subject: Re: untar.m on Solaris with non-GNU tar
Date: Tue, 24 Oct 2006 22:45:25 -0400

On 20-Oct-2006, Bill Denney wrote:

| John W. Eaton wrote:
| > You don't really need varargin for a function like this.  It might be
| > clearer to write
| >   
| Whatever style you prefer.
| > Also, it looks like we are always asking unpack to get and return the
| > file list, even if it is not requested.  Should we maybe make it so
| > that step is avoided if we don't want it (omit the -v options in the
| > commands used by unpack and the output parsing if nargout is zero)?
| >   
| I don't see a straightforward way to keep the command list persistent 
| and to omit the -v options.  If you prefer not getting the output when 
| it's not requested, then it seems that the persistence must go (or 
| things would have to get much more spaghetti-like).

At first I thought to use

  commandlist.targz = {"gunzip -c \"%s\" | tar -x %s", @__parse_tar__, false};

and substitute the verbose option (or not) for the second %s, but then
I saw that in some commands the file name appears before the verbose
option and sometimes it appears after.  So instead of that, what about
using something like

  commandlist.targz = {{"gunzip -c \"%s\" | tar -x -v", ...
                        "gunzip -c \"%s\" | tar -x"}, ...
                       @__parse_tar__, false};


  [commands, parser, move] = deal (commandlist.(nodotext){:});


  if (get_file_list)
    idx = 1;
    idx = 2;

  [status, output] = system (sprintf (commands{idx}, file));

BTW, I think 2>&1 is a Unixism, so inserting that in the command
string will likely cause trouble on Windows systems unless we can
assume a Unixy shell.

| > Also, we could use mfilename to get the last arg for unpack.  Then all
| > these functions could be identical except for the function names.
| >
| >   function varargout = bunzip2 (files, outputdir)
| >     if (nargin == 1 || nargin == 2)
| >       if (nargin == 1)
| >     outputdir = ".";
| >       endif
| >       varargout = cell (1, nargout);
| >       [varargout{:}] = unpack (files, outputdir, mfilename ());
| >     else
| >       print_usage ();
| >     endif
| >   endfunction
| >   
| That does make more sense.
| > Hmm, don't see a way to push any of this duplication into the unpack
| > function given its current definition, but if print_usage accepted an
| > argument, then I suppose we could write
| > [functions that call another intermediate function]
| > OTOH, maybe that is going too far.
| >   
| I can see a use for doing it like that, but I don't expect that we'll 
| have too many more of these decompression functions


| (the only things 
| that are missing off the top of my head are rar, arj, and 7zip, and I 
| don't really expect to need those, personally),

I don't think we need them.

| so I think that 7 more 
| lines of code in about 5 files isn't too bad.

Yes, I think it is OK.  Can you make the changes I suggested
(eliminate varargin, only compute and return the file list if it is
requested) and submit new versions?  Then I'll check in the changes.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]