我正在维护一些旧脚本，我遇到了这个：
tar -cvf - ${files} | gzip -n -c | openssl ...
这个和更紧凑的没有任何实际区别，没有“-n”到gzip？还有其他方法可以在tar命令中将“-n”传递给gzip吗？
tar -cvzf - ${files} | openssl ...
这是在Linux 3.0.101-0.47.71-default上。我预计会有轻微的性能改善，但我担心的是不会导致下游的变化。
答案 0 :(得分：2)
旧版tar内置了gzip压缩版。在我知道的任何gzip上，n在通过stdin投放时没有任何意义。当然，除了将gzip数据中的压缩时间戳设置为0之外。
我怀疑这个选项的用处，说实话 - 在我能测试的任何事情上，大小保持不变。这是正确的行为 - 标题（在RFC 1952, Sec. 2.2中指定）自纪元以来只有几秒钟的4B timespec - 如果将其设置为0，则表示“没有省时间规划”。因此，除非您需要不让gzip数据的接收者知道它何时被压缩，-n没有任何好处。 （如果您有一些基于未知时序的身份验证方案，例如，自启动设备以来生成的会话ID，可能会有遗漏此类时间戳的安全优势，但坦率地说，我宁愿担心插入这些安全漏洞而不是将时间戳设置为零。）
答案 1 :(得分：2)
事实证明，可能存在显着差异。至少对于我正在使用的tar（macOS上的默认tar）。当写入stdout时，tar以块的形式写入所有输出，用零填充以完成最后一个块，即使在压缩数据之后进行压缩，填充也是如此。这在手册页中有记录，因此它不是错误。默认块大小为10K。使用默认阻塞因子，tar -cvzf的结果几乎总是大于tar -cvf ... | gzip，平均为5K。
从手册页：
All archive output is written in correctly-sized blocks, even if the out-
put is being compressed. Whether or not the last output block is padded
to a full block size varies depending on the format and the output
device. For tar and cpio formats, the last block of output is padded to
a full block size if the output is being written to standard output or to
a character or block device such as a tape drive. If the output is being
written to a regular file, the last block will not be padded. Many com-
pressors, including gzip(1) and bzip2(1), complain about the null padding
when decompressing an archive created by tar, although they still extract
it correctly.
我正在使用bsdtar 2.8.3。
GNU tar 1.29没有这样做，尽管文档似乎表明它应该：
If the output goes directly to a local disk, and not through stdout,
then the last write is not extended to a full record size. Otherwise,
reblocking occurs.
文档继续注意gzip抱怨尾随零的相同问题。然而，当通过标准输出时，没有尾随零。