[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};
then
[commands, parser, move] = deal (commandlist.(nodotext){:});
and
if (get_file_list)
idx = 1;
else
idx = 2;
endif
[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
OK.
| (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.
Thanks,
jwe
- Re: untar.m on Solaris with non-GNU tar, (continued)
- Re: untar.m on Solaris with non-GNU tar, Bill Denney, 2006/10/20
- Re: untar.m on Solaris with non-GNU tar, John W. Eaton, 2006/10/20
- Re: untar.m on Solaris with non-GNU tar, Bill Denney, 2006/10/20
- Re: untar.m on Solaris with non-GNU tar, Bill Denney, 2006/10/20
- Re: untar.m on Solaris with non-GNU tar, John W. Eaton, 2006/10/20
- Re: untar.m on Solaris with non-GNU tar, Bill Denney, 2006/10/20
- Re: untar.m on Solaris with non-GNU tar,
John W. Eaton <=
- Re: untar.m on Solaris with non-GNU tar, Bill Denney, 2006/10/24
- Re: untar.m on Solaris with non-GNU tar, John W. Eaton, 2006/10/24