- Trying to unzip a file, ‘Filename not matched’ when the directory exists
- Solution 2
- Solution 3
- Solution 4
- Solution 5
- Related videos on Youtube
- Suhail Gupta
- Comments
- Unzipping a batch of files
- You must log in to answer this question.
- Related
- Hot Network Questions
- Subscribe to RSS
- Trying to unzip a file, ‘Filename not matched’ when the directory exists
- 6 Answers 6
- Why doesn’t this unzip all my files in a given directory?
- Solution
- Example
- Note
Trying to unzip a file, ‘Filename not matched’ when the directory exists
You can also get this when trying to specify the files to unzip and using a wildcard character. For example:
unzip -o somearchive.zip somedir/*
What may happen is that bash expands somedir/* to an actual existing dir and the files it contains. That list is then passed to unzip and it tries to find these files in the zip file.
To prevent this behavior just escape the * like this:
unzip -o somearchive.zip somedir/\*
Or, put the files to extract in double quotes:
unzip -o somearchive.zip "somedir/*"
Solution 2
You will also get that error if you try to unzip a whole directory of zips with a single command, like:
I found the solution on another site. The * symbol must be escaped, so you should run this instead:
Solution 3
The file name argument after the archive name specifies a file to extract. Use -d to specify the target directory:
Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir] . -d extract files into exdir
Moreover, -Z is used to querying the archive, not extracting.
Solution 4
This exact command worked for me:
unzip -o archive.zip -d /Users/current/Dev/tools/
Notice the combination of options -o & -d (destination/inflation path).
Solution 5
Trying to unzip a zipped file with a new name will raise the ‘Filename not matches’ exception. To workaround this move the zip file to the destination directory
navigate to the destination directory
from there run the unzip command without the destination filename argument
Everything will work well.
so in this case the commands should be
[[email protected] Joomla]# mv Joomla_3.0.3-Stable-Full_Package.zip /opt/lampp/htdocs/joomla/ [[email protected] Joomla]# cd /opt/lampp/htdocs/joomla/ [[email protected] Joomla]/opt/lampp/htdocs/joomla# unzip Joomla_3.0.3-Stable-Full_Package.zip
Related videos on Youtube
Suhail Gupta
Updated on September 18, 2022
Comments
While trying to unzip a file named Joomla_3.0.3-Stable-Full_Package.zip to the directory named joomla I get filename not matched. Why is that?
# unzip -Z Joomla_3.0.3-Stable-Full_Package.zip /opt/lampp/htdocs/joomla/ Archive: Joomla_3.0.3-Stable-Full_Package.zip caution: filename not matched: /opt/lampp/htdocs/joomla/
Here is the screen cast of the directory: (The joomla directory is empty)
@SuhailGupta: unzip -d /opt/lampp/htdocs/joomla/ Joomla_3.0.3-Stable-Full_Package.zip , i.e. drop -Z , add -d .
You might also get the ‘Filename not matched’ error when your -o flag is in the wrong place: unzip -o ARCHIVE_NAME.zip is good while unzip ARCHIVE_NAME.zip -o is bad
Downvoting because, although this answer makes true statements, they don’t address the issue the OP has, which is a misunderstanding about that arguments to unzip.
This doesn’t make any sense to me, at least not if you’re talking about Unix / Linux. (It might make sense if you’re talking about Windows, but this question is about Fedora Linux.) And, to the extent that it does make sense (potentially), it appears to be a duplicate of sjbotha’s answer. Can you explain what you mean more clearly?
i was talking about the unzip command that i used on a linux system. i had a directory with many zip files and i tried to extract them all with unzip *.zip and got that error because the * was not escaped. you might also be right about this not belonging here since the op just tried to extract one zip file and i was trying to extract many with one command.
Unzipping a batch of files
Thanks. This might nit match the actual question perfectly but this solved my problem. I was trying unzip * and it returned caution: filename not matched for every file but unzip ‘*.zip’ did the job.
Your commands are not working because they stuff all the files onto the same command line. While that works with most programs, unzip will take the first argument as the zip file, and any after the first as files to extract from it. You need to execute the command once for each file:
find . -name "*.zip" -print0 | xargs -0 -n1 unzip
find . -name '*.zip' -exec unzip <> \;
The second one seems to be better in case there really are a lot of files. (Otherwise it complained the command is too long with xargs)
In bash you could also do the following:
for i in *.zip; do unzip "$i" done
Also unzip can take the -d switch so you can target the output to different locations.
uzdir=/path/to/unzips for i in *.zip; do [ -d "$uzdir/$i" ] || mkdir -p "$uzdir/$i" unzip "$i" -d "$uzdir/$i" done
There is a much easier solution than the looping ones given above, use the directory -d flag:
unzip -o somefiles.zip -d $directoryPath
You must log in to answer this question.
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.12.43529
Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group.
This site is not affiliated with Linus Torvalds or The Open Group in any way.
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
Trying to unzip a file, ‘Filename not matched’ when the directory exists
While trying to unzip a file named Joomla_3.0.3-Stable-Full_Package.zip to the directory named joomla I get filename not matched. Why is that?
# unzip -Z Joomla_3.0.3-Stable-Full_Package.zip /opt/lampp/htdocs/joomla/ Archive: Joomla_3.0.3-Stable-Full_Package.zip caution: filename not matched: /opt/lampp/htdocs/joomla/
Here is the screen cast of the directory: (The joomla directory is empty)
6 Answers 6
You can also get this when trying to specify the files to unzip and using a wildcard character. For example:
unzip -o somearchive.zip somedir/*
What may happen is that bash expands somedir/* to an actual existing dir and the files it contains. That list is then passed to unzip and it tries to find these files in the zip file.
To prevent this behavior just escape the * like this:
unzip -o somearchive.zip somedir/\*
Or, put the files to extract in double quotes:
unzip -o somearchive.zip "somedir/*"
You might also get the ‘Filename not matched’ error when your -o flag is in the wrong place: unzip -o ARCHIVE_NAME.zip is good while unzip ARCHIVE_NAME.zip -o is bad
Downvoting because, although this answer makes true statements, they don’t address the issue the OP has, which is a misunderstanding about that arguments to unzip.
Also commenting the solution is to add -d before the target directory, as in the answer below: superuser.com/a/563232/388883
You will also get that error if you try to unzip a whole directory of zips with a single command, like:
I found the solution on another site. The * symbol must be escaped, so you should run this instead:
This doesn’t make any sense to me, at least not if you’re talking about Unix / Linux. (It might make sense if you’re talking about Windows, but this question is about Fedora Linux.) And, to the extent that it does make sense (potentially), it appears to be a duplicate of sjbotha’s answer. Can you explain what you mean more clearly?
i was talking about the unzip command that i used on a linux system. i had a directory with many zip files and i tried to extract them all with unzip *.zip and got that error because the * was not escaped. you might also be right about this not belonging here since the op just tried to extract one zip file and i was trying to extract many with one command.
Why doesn’t this unzip all my files in a given directory?
This command itself is invalid on the level of find , it doesn’t even get to a point where unzip runs. A valid -exec action inside a find command is terminated either by + or by \; *, not by both at the same time. Your description matches the behavior of the action terminated by + only, so I assume this was the command you really used:
find -name "*.zip" -exec unzip <> + # still wrong
Why doesn’t this unzip all the zip files in a given directory?
Because unzip expects exactly one zip file. Additional operands are interpreted as «archive members to be processed» (see man 1 unzip ), i.e. files you want to extract from the archive. By using -exec unzip <> + you invoke unzip with possibly multiple arguments from the expansion of <> . All arguments but the first are interpreted as archive members to be processed, but you don’t want them to be treated as such.
* Strictly: ; . The backslash in \; is just to escape ; in a shell, so the shell does not treat ; as command terminator. The shell strips the backslash and find sees ; as it should.
Solution
Use -exec unzip <> \; instead. This form will replace <> with exactly one pathname. It will spawn more unzip processes than -exec unzip <> + would, but each unzip will get exactly one zip file to process and this is what the tool expects.
find . -type f -name "*.zip" -exec unzip <> \;
I explicitly specified . as the starting path to make the answer portable. Your find apparently uses . by default, but some implementations of find require at least one path in the command line. -type f is in case some directory (or a socket etc.) matched -name «*.zip» ; in general it may.
Example
Imagine there are ./foo.zip and ./bar.zip as the only matching files. find -name «*.zip» -exec unzip <> + will execute:
(or unzip ./bar.zip ./foo.zip ). This command will try to extract ./bar.zip from ./foo.zip (or the other way around, respectively). This is not what you want to do.
On the other hand find -name «*.zip» -exec unzip <> \; will execute:
unzip ./foo.zip unzip ./bar.zip
or the same pair of commands in reverse order. This is what you want to do.
Note
The order in the above example is not specified. In practice this answer is basically true:
find will be traversing the directory tree in the order items are stored within the directory entries. […]
In theory find is not required to traverse in this order, it just happens it’s a convenient order to implement.
Anyway, in your case if files extracted from one zip collide with files stored in another zip then at some point unzip will ask you what to do. Pay attention to what archive the question is about; do not assume any particular order of archives.