[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: Bill Denney
Subject: Re: untar.m on Solaris with non-GNU tar
Date: Fri, 20 Oct 2006 23:31:41 -0400
User-agent: Thunderbird (Windows/20060909)

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).
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 = ".";
      varargout = cell (1, nargout);
      [varargout{:}] = unpack (files, outputdir, mfilename ());
      print_usage ();
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), so I think that 7 more lines of code in about 5 files isn't too bad.


reply via email to

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