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.

3
  • Side note: is unzip -j $filename just an example? if it's a part of your script, make it unzip -j "$filename". Jun 8, 2018 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) Jun 8, 2018 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. Jun 8, 2018 at 18:19

1 Answer 1

3

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'
8
  • 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 Jun 8, 2018 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 \ Jun 8, 2018 at 18:04
  • I guess I will replace $filename with '*.report.xml'... Thanks! Jun 8, 2018 at 18:06
  • Where do we file a bug report for unzip? although will be a few years until corporate distros get it :) Jun 8, 2018 at 18:06
  • @Carmageddon Bug report? Frankly I don't know. Note: similar situation with unrar. Jun 8, 2018 at 18:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .