在我的场景中，什么可能导致解压缩命令返回 -1？答案

【问题标题】：What could cause unzip command returning -1 in my scenario?在我的场景中，什么可能导致解压缩命令返回 -1？
【发布时间】：2017-08-20 07:57:59
【问题描述】：

我通过system() 调用在我的 C++ 代码中运行解压缩，格式如下：

/usr/bin/unzip -o -q /<my_path_to_zip_file>/cfg_T-KTMAKUCB.zip -d /<my_path_to_dest>/../

这几乎 90% 的时间都会成功。我无法理解是什么可能导致它不时使用 -1 返回码。有什么想法吗？

【问题讨论】：

请分享您的unzip 版本。
为什么不将错误流通过管道传输到日志文件？您可以创建一个运行命令约 100 次的单元测试，然后检查日志文件以查看错误是什么？
调用程序的用户是否拥有访问目录所需的所有权限？设备上是否有足够的空间来解压缩文件？如果您使用sudo 运行该程序有帮助吗？另外，system() 返回的-1 并不代表它是unzip 的返回值（详见man 3 sleep）。提供更多信息
@Rogus 正如他所说，它在大多数情况下都有效，权限和 sudo 显然不是解决方案。磁盘大小可能是，但我认为这不太可能。关于返回码的好点。事实上， unzip 永远不会返回
在您的问题中，您说的是“-1 返回码”，而不是 errno。你在检查什么errno？我相信 errno 是唯一的进程，因此您无法访问解压缩的 errno。也许您应该调查“explain_system()”。 "explain_system 函数用于获取 system(3) 系统调用返回的错误的解释。消息将包含的最少是 strerror(errno) 的值，但通常它会做得更好，并指示底层原因更详细。"

【解决方案1】：

据我当地的man system，

出错时返回-1（例如fork(2)失败），否则返回命令状态。

如果无法创建子进程，或者无法获取命令语言解释器的终止状态，system() 将返回 -1 并设置 errno 以指示错误

最后，unzip 的手册页列出了各种返回码，但 -1 不在其中。

如果命令本身不能返回 -1，则问题可能出在初始 fork/exec，原因是系统范围或每个用户的限制（内存耗尽；进程表已满；用户的最大进程、打开文件或 VM 大小限制等）。

当system 无论如何都失败时，您应该检查errno。在strace -f 下运行整个事情也会显示发生了什么。

【讨论】：

在初始fork/exec 上导致返回代码 -1 的好处。我可以确定的一件事是，我确信没有：“内存耗尽；进程表已满；最大进程、打开文件或 VM 大小限制”是原因。所以想知道strace -f 会给出什么。