(MingW] upack.m / tar.exe doesn't accept Windows-style path names

[Philip Nienhuis]

While trying to solve bug #44007 I run into some issues.

The root cause of bug #44007 is that on MinGW, tar.exe doesn't like Windows
style path and file names. I.e., "C:\some\file" isn't accepted, but
"/c/some/file" is. On Windows, tar.m simply conveys Windows style path names
as-is to tar.exe and that's the reason tar.m doesn't work there. Looking in
tar.m's file history I think this bug may have been around for a long time.
In principle there's an easy fix in tar.m (see proposed fix in the bug
report), and it works fine. And -bonus!- in passing the actual bug #44007 is
solved as well; while the xtest still fails, one does get back to the
original working dir.

But while trying to also fix the xtest itself, I got stuck with the untar
command a few lines further down in the failing tar.m xtest.  The thing is
that untar.m doesn't directly call tar.exe itself but calls unpack.m, that
in turn prepares a "system" command "tar xv ....".
Mending the Windows style full path names in untar.m analogously as in tar.m
doesn't help, as in unpack.m the Windows style path names are still required
for glob(); on MingW, glob doesn't want to accept mingw style file/path
names.
So there we are: on Windows:
- some mingw utilities in unpack.m insist on full path names in mingw style;
but:
- some Octave functions called in the same function file want full path
names in Windows style.

Some experimenting shows that it's only the "tar" executable that is picky
as regards filenames.  gzip.exe, unzip.exe and bzip2.exe happily accept
Windows style full path names (albeit with forward slashes).

The best solution would be to fix tar.exe so that on MingW it accepts
Windows style path names, if possible. I'll ask on the mingw-users ML if it
is a known issue.

For now, it is of course possible to put some path conversion fix just for
tar files in an appropriate location in unpack.m. That would be my
suggestion.

Q's:
1. Would that be an acceptable solution, or is it considered too messy?

2. Why is untar.m calling unpack.m in the first place? Its inverse sibling
tar.m doesn't call some "pack.m". The current setup looks quite (if not
needlessly) involved to me. 
(Same for e.g., gzip.m, bzip2.m, etc.).

Thanks,

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/MingW-upack-m-tar-exe-doesn-t-accept-Windows-style-path-names-tp4668172.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.