2

So I have a script that iterates over zip files, lists their content with unzip -l $filename, and looks for matches to pattern (.*)report.xml, in this case yields test0\report.xml

But when it tries to unzip using unzip -j $filename, I get caution: filename not matched: test0\report.xml

I stopped and tried manually on a file which lists:

7285 2018-05-04 13:34 test0\report.xml

Then doing

unzip -j 2747693b-7027-44d3-98f4-a01f1ed139cf.zip test0\report.xml

Gives me the error caution: filename not matched: test0report.xml

I tried calling with \\ to escape it, then same error but saying test0\report.xml instead.

I tried everything like \, or /, or // so I dont think this is backwards slash escaping issue.

Please help.

Carmageddon
  • 277
  • 1
  • 3
  • 9
  • Side note: is `unzip -j $filename` just an example? if it's a part of your script, make it `unzip -j "$filename"`. – Kamil Maciorowski Jun 08 '18 at 18:00
  • Ok, why? it worked for all other files I needed to extract so far from other archives (they were not in a subdir with wrong slash, howeveR) – Carmageddon Jun 08 '18 at 18:15
  • 1
    If the variable contains spaces etc., the command will get more arguments than you expect and they won't be sane. If you're sure spaces cannot happen, you may get away with unquoted shell variable. Still, it's a good general practice to quote. – Kamil Maciorowski Jun 08 '18 at 18:19

1 Answers1

2

I have recreated the issue in my Kubuntu. The file name was literally test0\report.xml and when I did

unzip -j foo.zip test0\\report.xml

unzip returned filename not matched: test0\report.xml although the string it got should match, I think.

The tool supports some wildcards. I was able to unzip the file with this command:

unzip -j foo.zip 'test0?report.xml'

A bug? I guess you have to add some logic to your script or just to unzip by hand whenever such (hopefully rare) situation occurs again. Or take advantage of these wildcards supported by unzip and instead of matching (.*)report.xml in the script let unzip do the job:

unzip -j foo.zip '*report.xml'
Kamil Maciorowski
  • 69,815
  • 22
  • 136
  • 202
  • Interesting observation! Not correct however, I just downloaded the zip file to my windows machine to test, the test0 is a directory, containing report.xml. However your work around does work! I do get the `warning: 2747693b-7027-44d3-98f4-a01f1ed139cf.zip appears to use backslashes as path separators` – Carmageddon Jun 08 '18 at 18:02
  • Now I have another problem... My script was using unzip -j $i $filename - now I need to find a way to put a question mark instead of ```\``` – Carmageddon Jun 08 '18 at 18:04
  • I guess I will replace `$filename` with `'*.report.xml'`... Thanks! – Carmageddon Jun 08 '18 at 18:06
  • Where do we file a bug report for unzip? although will be a few years until corporate distros get it :) – Carmageddon Jun 08 '18 at 18:06
  • @Carmageddon Bug report? Frankly I don't know. Note: [similar situation with `unrar`](https://superuser.com/q/544786/432690). – Kamil Maciorowski Jun 08 '18 at 18:08
  • Ok, thats not working in my script :( When I do `unzip -j $i '*report.xml'#$filename` - I get error `caution: filename not matched: *report.xml#test0\report.xml` $i being the zip filename currently being looped – Carmageddon Jun 08 '18 at 18:38
  • @Carmageddon I don't know what you're trying to do with this code. I was referring to "script […] looks for matches to pattern `(.*)report.xml`" and advised you to make `unzip` handle all the matching – like `unzip -j "$i" '*report.xml'`. – Kamil Maciorowski Jun 08 '18 at 18:42
  • never mind, it worked :) I think I had to wrap $i in quotation just like you showed here... it still complains and cautions, but it inflated the files. Thanks! – Carmageddon Jun 08 '18 at 20:29