Date: Fri, 9 Sep 94 02:43:20 CDT
From: "Cave Newt" <roe2 AT midway DOT uchicago DOT edu>
To: Zip-Bugs AT wkuvx1 DOT wku DOT edu, g3jhntsz AT cdf DOT toronto DOT edu
Subject: Re:  unzip386.exe in UnZip 5.12
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu

John T. Chiu wrote:

>  I've just upgraded from UnZip 5.11 to UnZip 5.12
>  
>  I used to put "c:\unzip386\unzip386.exe -a %1 -d d:\" without quotes
>  in a batch file to decompress zip-files.
>  
>  Apparently, unzip386.exe in UnZip 5.12 has difficulty in
>  interpreting options and/or file name and/or directory name
>  when unzip386.exe is invoked in a batch file.
>  
>  In version 5.11, there's no such problem.

By golly, you've discovered...something.  Without reading the djgpp docs
I can't tell for sure if this is a weird consequence of "working as in-
tended" or if it's a full-fledged bug.  The problem goes away if you add 
a space after the trailing backslash.  Apparently go32 treats trailing
backslashes as line-continuation characters (as in Unix); the bug, such
as it is, is in not doing bounds checking and noticing that there isn't
any second line, but instead passing garbage on the command line to the 
invoked program.

[For those who are too lazy to try it, you get something like this:

C> dounzip foo.zip
Archive:  foo.zip
caution: filename not matched:  pping
caution: filename not matched:  happens,
caution: filename not matched:  and
caution: filename not matched:  should
caution: filename not matched:  be
caution: filename not matched:  a
caution: filename not matched:  real
caution: filename not matched:  drive

which would correspond to an unzip command line like:

c:\unzip386\unzip386.exe -a foo.zip -d d:\ pping happens, and should be a real drive

The text can be offset/duplicated, but you get the general idea.  It looks 
like some random string in go32 itself is getting tossed onto the command 
line (or maybe that's just the previous contents of the stack?).  I'm 99% 
certain that text does not occur anywhere in UnZip.]

Greg Roelofs