[Octave-bug-tracker] [bug #47578] zip/gzip/bzip2 fail when run from inside a path with spaces in name

[Philip Nienhuis]

Follow-up Comment #7, bug #47578 (project octave):

Experimenting with invoking octave's zip. and gzip.m showed the following:
- gzip.m works, after some messing with file and path names
- zip.m does NOT work
for subdirs with spaces in the path name.

Following the code in zip.m I see:

cmd = sprintf ("zip -r %s %s", zipfile, sprintf (" %s", files{:}))
[status, output] = system (cmd)

...which after translation of:

zipfile                   -> filename
sprintf (" %s", files{:}) -> *.* .


is essentially the same as

[stts, op] = system (sprintf ("zip -q -r %s *.* .", filename))


in OF-io's private/__OCT_spsh_close__.m

I found that the only thing I needed to do to make my original code work in
subdirs with spaces in the name was to change the statement:

[stts, op] = system (sprintf ("zip -q -r %s *.* .", filename))


into:
+verbatim-
[stts, op] = system (sprintf ('zip -q -r "%s" *.* .', filename))


i.e., essentially put double quotes around the zipfile name and single quotes
around the sprintf format string.
Patching similarly for the original gnumeric (gzip) files statement made that
work as well.

So my point here is:
I'd think similar holds for octave's zip.m (and maybe gzip.m and bzip2.m) for
them to work properly on Windows in subdirs with spaces in the name.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47578>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/