octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #47609] zip.m: errrors when zipping to a direc


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #47609] zip.m: errrors when zipping to a directory with spaces in name on Windows
Date: Sun, 03 Apr 2016 16:55:48 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38

Follow-up Comment #4, bug #47609 (project octave):

@comment #3:
 *.*  on Windows is usually meant to catch all files and subdirs, with or
without extension (on Windows files and directories can have extensions;
extensions of directories are not special, just part of a name). 
That works differently on *nix - the period between file/directory name and
extension isn't special on *nix (and msys/mingw and cygwin), while it is on
Windows (that is, Windows utilities and -programs find it special => Windows
users perceive it as special too).
I found that  *.*  even works adversely on mingw, see the first two verbatim
blocks in comment #1, hence my advice in the texinfo header in the changeset.

Of course zip.m can have stanza along the lines of:

if (ispc && strcmp (files, "*.*"))
  files = "*";
endif


but I think it is better to have users know what they're doing than have
programs guessing user's intentions. After all, it may be possible that a
literal  *.*  is required and/or intended.


@comment #2:
The cmd lines obtained in zip.m that are conveyed to zip.exe are in the 5th
verbatim block of comment #1.

The purpose of my cset is simply to ensure properly zipping to directories
with spaces in the name using zip.m *on Windows systems*.
On Linux, zip.m and friends work as advertised, probably due to Rik's recent
work.

Backslashes give problems when fed to zip(.exe), see the 5th verbatim block in
comment #1 (debugging zip.m on Windows).
Several mingw utilities behave inconsistently as regards file separator
styles.  zip.exe is a fine example: it does not error on backslashes in its
first argument (the zip file) but does in the second (the files to be zipped).
I did not include that in the verbatim block, but that's what I got while
experimenting.

One can argue that backslash behavior had rather be fixed upstream, but I
think for now it is vastly better to simply avoid backslash fileseps at all
when dealing with mingw utilities.  All of those those work fine with forward
slash fileseps.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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