tar -xvzf $ filename.tar.gz || {exit $？; }
这里我的脚本将以errorCode 141退出。我正在使用带有tar版本1.15的Fedora Core 6
它不会一直发生，但超过70％的时间都会失败。
答案 0 :(得分：19)
我意识到这个帖子已经有几年了，但是我正在评论那些偶然发现错误的人。
每当使用压缩选项时，tar都会使用管道隐式打开与底层程序的连接。因此，在OP的示例中：tar -xvzf $filename.tar.gz，tar实际上会执行类似于此的操作：gunzip $filename.tar.gz | tar -xv -。您可以通过运行top来验证这一点，在那里您将看到两个进程（一个用于tar，一个用于gzip）。
有时候，管道本身会破裂。例如，如果文件不是gzip文件。以此为例：tar -xvzf somefile.iso，相当于gunzip somefile.iso | tar -xv -。在这种情况下，gzip会出错。当gzip错误输出时，管道将中断。另一种可能性是如果gzip文件是正确的，但其中的tar文件已损坏。在这种情况下，gzip开始将未压缩的流发送到tar，但随后tar意识到出错了并关闭了流。然后gzip会出错，因为它的输出已关闭。
在退出值中，大于128的值表示由于信号而终止，而大于128的值表示哪个信号导致终止。因此，如果我们从OP的退出代码141中减去128，我们得到13，这对应于SIGPIPE（man 7 signal以获得标准信号列表及其对应的整数值。）
手册页将SIGPIPE的评论列为“破管道：写入没有读者的管道”。那么，似乎gzip正试图写入管道，但tar已停止监听。我的猜测是gzip成功解压缩文件，但未压缩的流不是有效的tar存档。我的建议是在文件上运行gunzip，然后在结果文件上运行tar并查看哪一个失败（基于SIGPIPE，我的猜测是tar会失败）。在任何一种情况下，看起来这些工具的版本都无法读取该文件（损坏或某种版本冲突）。
这些文件是如何制作的（tar等选项有哪些）？ 它们是在这台机器还是其他机器上创建的？ 如果您在此计算机上创建.tar.gz文件，同一台计算机是否可以在没有错误的情况下提取这些文件？
答案 1 :(得分：1)
GNU tar只返回一些东西，它们都不是-141。但是，如果它正在运行子进程（如gzip），并且该进程异常终止，则返回 返回代码。
我不确定子进程可能是什么。尝试使用--verbose并查看是否有任何线索。
答案 2 :(得分：0)
作为一种解决方法，我们现在使用cpio进行归档，这对我们来说现在很好用，虽然我想知道为什么tar导致了这个问题，它长期存在，并且多年来一直被用作标准工具。 / p>