View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000549 | Other Unix Port | Bug | public | 2012-10-08 09:26 | 2019-10-08 21:34 |
| Reporter | DB1 | Assigned To | psmedley | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | T23 | OS | ECS | OS Version | 2.0 |
| Summary | 0000549: Unzip is not doing wild carding correctly. | ||||
| Description | Or 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". | ||||
| Tags | No tags attached. | ||||
|
|
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 |
|
|
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 |
|
|
OK I better understand the 2nd example now, will try investigate it. |
|
|
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.) |
|
|
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. |
|
|
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 |
|
|
Use version from rpm |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-10-08 09:26 | DB1 | New Issue | |
| 2012-12-16 08:33 | psmedley | Note Added: 0002374 | |
| 2012-12-16 14:52 | DB1 | Note Added: 0002376 | |
| 2012-12-16 19:45 | psmedley | Note Added: 0002378 | |
| 2013-06-01 13:58 | LewisR | Note Added: 0002454 | |
| 2013-06-01 14:22 | DB1 | Note Added: 0002455 | |
| 2013-06-01 15:23 | LewisR | Note Added: 0002456 | |
| 2019-09-29 01:18 | psmedley | Assigned To | => psmedley |
| 2019-09-29 01:18 | psmedley | Status | new => closed |
| 2019-09-29 01:18 | psmedley | Resolution | open => fixed |
| 2019-09-29 01:18 | psmedley | Note Added: 0003343 |
