View Issue Details

IDProjectCategoryView StatusLast Update
0000549Other Unix PortBugpublic2019-10-09 08:04
ReporterDB1Assigned Topsmedley 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformT23OSECSOS Version2.0
Summary0000549: Unzip is not doing wild carding correctly.
DescriptionOr at least not the same as it used to.

I was using UnZip 5.52 of 28 February 2005.

I have on drive T a back up of drive H.

On root of H

unzip -l t:/backup/h.zip home/db/foo/*

lists just the directory

unzip 5 lists the contents as well - as expected.

Change to the directory on T and unzip 6 now lists the contents too.

With unzip 5 I can do

unzip *h.zip and it will go down all <something>h.zip files but unzip 6 only does the first zip file. unzip -l *h.zip lists the first and then lists the rest as "file not found".
TagsNo tags attached.

Activities

psmedley

2012-12-16 19:03

administrator   ~0002374

http://smedley.id.au/unzip60-20121216.zip seems to work per your first example here.

This is a fresh compile of the most recent source I have on my drive - possibly newer than I had previously released

DB1

2012-12-17 01:22

reporter   ~0002376

Well it's different :-)

unzip -l t:/backup/h.zip home/db/foo/*

Now list the files.

But the other still fails:

Your latest:

[T:\Backup\paddington]t:\tmp\unzip.exe -l h*.zip home/db/clip*
Archive: H-0.zip
  Length EAs ACLs Date Time Name
--------- --- ---- ---------- ----- ----
     1078 0 0 28-10-2012 17:34 home/DB/ClipProcess
--------- ----- ----- -------
     1078 0 0 1 file


unzip 5.52:
[T:\Backup\paddington]unzip.exe -l h*.zip home/db/clip*
Archive: H-0.zip
  Length EAs ACLs Date Time Name
 -------- --- ---- ---- ---- ----
     1078 0 0 28-10-12 17:34 home/DB/ClipProcess
 -------- ----- ----- -------
     1078 0 0 1 file

Archive: H-1.zip
  Length EAs ACLs Date Time Name
 -------- --- ---- ---- ---- ----
     1082 0 0 07-10-12 16:23 home/DB/ClipProcess
 -------- ----- ----- -------
     1082 0 0 1 file

Archive: H-2.zip
  Length EAs ACLs Date Time Name
 -------- --- ---- ---- ---- ----
     1066 0 0 18-09-12 17:57 home/DB/ClipProcess
 -------- ----- ----- -------
     1066 0 0 1 file

psmedley

2012-12-17 06:15

administrator   ~0002378

OK I better understand the 2nd example now, will try investigate it.

LewisR

2013-06-01 23:28

developer   ~0002454

Ugh... I had a long note added here, and it wouldn't take. I usually copy such things to my clipboard before submitting, not trusting the browser, but I neglected that step this time. :-\

Dave, can you try:

unzip.exe -l "h*.zip" home/db/clip*

and see what you get with Paul's build or with Yuri's 3/29/2013 one? If you don't have YUM/RPM handy, grab the zip from my server:

ftp://ftp.2rosenthals.com/pub/os2/unzip-6.0-5.zip

I think something crept into Unzip between 5.5.2 and 6.0 which changed this behavior. Even with the WILD_STOP_AT_DIR compile time option in the build I'm using on openSUSE 12.2, I get the same behavior, so that's not it.

Paul, you might want to look at that option; I haven't thought too deeply into it, though, and how it might impact us on OS/2. From the man page:

-W [only when WILD_STOP_AT_DIR compile-time option enabled] modi-
       fies the pattern matching routine so that both `?' (single-char
       wildcard) and `*' (multi-char wildcard) do not match the direc-
       tory separator character `/'. (The two-character sequence
       ``**'' acts as a multi-char wildcard that includes the directory
       separator in its matched characters.) Examples:

    "*.c" matches "foo.c" but not "mydir/foo.c"
    "**.c" matches both "foo.c" and "mydir/foo.c"
    "*/*.c" matches "bar/foo.c" but not "baz/bar/foo.c"
    "??*/*" matches "ab/foo" and "abc/foo"
            but not "a/foo" or "a/b/foo"

       This modified behaviour is equivalent to the pattern matching
       style used by the shells of some of UnZip's supported target OSs
       (one example is Acorn RISC OS). This option may not be avail-
       able on systems where the Zip archive's internal directory sepa-
       rator character `/' is allowed as regular character in native
       operating system filenames. (Currently, UnZip uses the same
       pattern matching rules for both wildcard zipfile specifications
       and zip entry selection patterns in most ports. For systems
       allowing `/' as regular filename character, the -W option would
       not work as expected on a wildcard zipfile specification.)

DB1

2013-06-01 23:52

reporter   ~0002455

Good catch Lewis. With the quotes it works like my current unzip without.

Yuri's won't run:

[T:\tmp\yuri]unzip -v
SYS1804: The system cannot find the file BZ2.

LewisR

2013-06-02 00:53

developer   ~0002456

Indeed, you need the bz2 dll, as he has bzip2 enabled (and not static). From YUM, it's just a:

yum install bzip2-libs

or, grab the dll from my server:

ftp://ftp.2rosenthals.com/pub/OS2/bzip-lib_1.0.6-5.zip

psmedley

2019-09-29 10:48

administrator   ~0003343

Use version from rpm

Issue History

Date Modified Username Field Change
2012-10-08 19:56 DB1 New Issue
2012-12-16 19:03 psmedley Note Added: 0002374
2012-12-17 01:22 DB1 Note Added: 0002376
2012-12-17 06:15 psmedley Note Added: 0002378
2013-06-01 23:28 LewisR Note Added: 0002454
2013-06-01 23:52 DB1 Note Added: 0002455
2013-06-02 00:53 LewisR Note Added: 0002456
2019-09-29 10:48 psmedley Assigned To => psmedley
2019-09-29 10:48 psmedley Status new => closed
2019-09-29 10:48 psmedley Resolution open => fixed
2019-09-29 10:48 psmedley Note Added: 0003343