Linux zip 命令不起作用
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/20529851/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
zip command not working
提问by Aparna Savant
I am trying to zip a file using shell script command. I am using following command:
我正在尝试使用 shell 脚本命令压缩文件。我正在使用以下命令:
zip ./test/step1.zip $FILES
where $FILES contain all the input files. But I am getting a warning as follows
其中 $FILES 包含所有输入文件。但我收到如下警告
zip warning: name not matched: myfile.dat
and one more thing I observed that the file which is at last in the list of files in a folder has the above warning and that file is not getting zipped.
还有一件事,我观察到文件夹中文件列表中的文件具有上述警告,并且该文件没有被压缩。
Can anyone explain me why this is happening? I am new to shell script world.
谁能解释我为什么会这样?我是 shell 脚本世界的新手。
回答by janos
zip warning: name not matched: myfile.dat
zip 警告:名称不匹配:myfile.dat
This means the file myfile.dat
does not exist.
这意味着该文件myfile.dat
不存在。
You will get the same error if the file is a symlink pointing to a non-existent file.
如果文件是指向不存在文件的符号链接,您将收到相同的错误。
As you say, whatever is the last file at the of $FILES
, it will not be added to the zip along with the warning. So I think something's wrong with the way you create $FILES
. Chances are there is a newline, carriage return, space, tab, or other invisible character at the end of the last filename, resulting in something that doesn't exist. Try this for example:
正如您所说,无论 的最后一个文件是什么$FILES
,它都不会与警告一起添加到 zip 中。所以我认为你创建的方式有问题$FILES
。有可能在最后一个文件名的末尾有换行符、回车符、空格、制表符或其他不可见字符,从而导致某些内容不存在。试试这个,例如:
for f in $FILES; do echo :$f:; done
I bet the last line will be incorrect, for example:
我敢打赌最后一行是不正确的,例如:
:myfile.dat :
...or something like that instead of :myfile.dat:
with no characters before the last :
...或类似的东西,而不是:myfile.dat:
在最后一个之前没有字符:
UPDATE
更新
If you say the script started working after running dos2unix
on it, that confirms what everybody suspected already, that somehow there was a carriage-return at the end of your $FILES
list.
如果你说脚本在运行后开始工作dos2unix
,那就证实了每个人都已经怀疑的事情,不知何故在你的$FILES
列表末尾有一个回车。
od -c
shows the \r carriage-return. Try echo $FILES | od -c
od -c
显示 \r 回车。尝试echo $FILES | od -c
回答by Aparna Savant
I converted my script for unix environment using dos2unix command and executed my script as ./myscript.sh instead bash myscript.sh.
我使用 dos2unix 命令为 unix 环境转换了我的脚本,并将我的脚本作为 ./myscript.sh 执行,而不是 bash myscript.sh。
回答by Mr.T
spaces are not allowed:
不允许使用空格:
it would fail if there are more than one files(s) in $FILES unless you put them in loop
如果 $FILES 中有多个文件,它将失败,除非您将它们放入循环中
回答by David L
I just discovered another potential cause for this. If the permissions of the directory/subdirectory don't allow the zip to find the file, it will report this error. Actually, if you run a chmod -R 444 on the directory, and then try to zip it, you will reproduce this error, and also have a "stored 0%" report, like this:
我刚刚发现了另一个可能的原因。如果目录/子目录的权限不允许zip找到文件,就会报这个错误。实际上,如果您在目录上运行 chmod -R 444 ,然后尝试对其进行压缩,则会重现此错误,并且还会出现“已存储 0%”报告,如下所示:
zip warning: name not matched: borrar/enviar adding: borrar/ (stored 0%)
zip 警告:名称不匹配:borrar/enviar 添加:borrar/(存储 0%)
Hence, try changing the permissions of the file. If you are trying to send them through email, and those email filters (like Gmail's) invent silly filters of not sending executables, don't forget that making permissions very strict when making zip compression can be the cause of the error you are reporting, of "name not matched".
因此,尝试更改文件的权限。如果您尝试通过电子邮件发送它们,并且那些电子邮件过滤器(如 Gmail 的)发明了不发送可执行文件的愚蠢过滤器,请不要忘记在进行 zip 压缩时非常严格的权限可能是您报告错误的原因, “名称不匹配”。
回答by chukko
回答by Dave Wood
Another possible cause that can generate a zip warning: name not matched:
error is having any of zip
's environment variables set incorrectly.
另一个可能导致zip warning: name not matched:
错误的原因是 的任何zip
环境变量设置不正确。
From the man page:
从手册页:
ENVIRONMENT
The following environment variables are read and used by zip as described.
ZIPOPT
contains default options that will be used when running zip. The contents of this environment variable will get added to the command line just after the zip command.
ZIP
[Not on RISC OS and VMS] see ZIPOPT
Zip$Options
[RISC OS] see ZIPOPT
Zip$Exts
[RISC OS] contains extensions separated by a : that will cause native filenames with one of the specified extensions to be added to the zip file with basename and extension swapped.
ZIP_OPTS
[VMS] see ZIPOPT
In my case, I was using zip
in a script and had the binary location in an environment variable ZIP
so that we could change to a different zip
binary easily without making tonnes of changes in the script.
就我而言,我zip
在脚本中使用并在环境变量中具有二进制位置,ZIP
以便我们可以zip
轻松更改为不同的二进制文件,而无需在脚本中进行大量更改。
Example:
例子:
ZIP=/usr/bin/zip
...
${ZIP} -r folder.zip folder
This is then processed as:
然后将其处理为:
/usr/bin/zip /usr/bin/zip -r folder.zip folder
And generates the errors:
并生成错误:
zip warning: name not matched: folder.zip
zip I/O error: Operation not permitted
zip error: Could not create output file (/usr/bin/zip.zip)
The first because it's now trying to add folder.zip
to the archive instead of using it as the archive. The second and third because it's trying to use the file /usr/bin/zip.zip
as the archive which is (fortunately) not writable by a normal user.
第一个是因为它现在尝试添加folder.zip
到存档而不是将其用作存档。第二个和第三个是因为它试图将文件/usr/bin/zip.zip
用作(幸运的是)普通用户不可写的存档。
Note: This is a really old question, but I didn't find this answer anywhere, so I'm posting it to help future searchers (my future self included).
注意:这是一个非常古老的问题,但我没有在任何地方找到这个答案,所以我发布它以帮助未来的搜索者(包括我未来的自己)。
回答by Sean
I also encountered this issue. In my case, the line separate is CRLF in my zip shell script which causes the problem. Using LF fixed it.
我也遇到了这个问题。在我的情况下,单独的行是我的 zip shell 脚本中的 CRLF,这会导致问题。使用 LF 修复它。