tar -xvzf $filename.tar.gz || { exit $?; }
这里的脚本将以错误代码141退出。我使用的是Fedora Core 6和tar版本1.15。
虽然不是每次都会出现问题,但超过70%的时间它会失败。
tar -xvzf $filename.tar.gz || { exit $?; }
这里的脚本将以错误代码141退出。我使用的是Fedora Core 6和tar版本1.15。
虽然不是每次都会出现问题,但超过70%的时间它会失败。
我知道这个帖子已经有几年的时间了,但我为那些遇到错误而看到这篇文章的人做出评论。
每当您使用压缩选项时,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
以获取标准信号及其相应整数值列表)。
GNU tar 只会返回一些东西,其中没有 -141。但是,如果它正在运行子进程(例如 gzip),并且该进程异常终止,则会返回 该 返回代码。
我不确定子进程可能是什么。尝试使用 --verbose
并查看是否有任何线索。
作为一种解决方法,我们现在使用 cpio 进行归档,这对我们来说很有效,尽管我想知道为什么 tar 会引起这个问题,它已经存在很长时间了,并且作为标准工具使用多年。
tar
的输出被管道传输到另一个进程中并且该进程提前关闭了管道时,也会发生这种情况,例如tar -tf x.tar | head
或tar -tf x.tar | grep -q .
(head
在读取指定行数后关闭管道,grep -q
在找到匹配模式后立即关闭管道)。 - bain