我有 120 个带有 dos 行结尾的 .gz 文件（每个大约 5G），我的目标是将它们转换为 unix 行结尾，但我不想等待多天。
这是我目前的方法：
function conv() {
tmpfile=$(mktemp .XXXXXX)
zcat $1 > $tmpfile
dos2unix $tmpfile
gzip $tmpfile
mv $tmpfile.gz $1
}
for a in $(ls *.fastq.gz); do
echo "$a"
conv "$a" &
done
有没有办法在不拆包和重新包装的情况下修复行尾？
前几天，我从远程服务器收集了一些日志，然后不假思索地将文件压缩到一个文件中，而不是将目录添加到压缩包中。我可以手动分离出一些日志文件，但其中一些已经被 gzip 压缩了。所以原始文件看起来像：
ex_access.log
ex_access.log.1.gz
ex_access.log.2.gz
ex_debug.log
ex_debug.log.1.gz
ex_debug.log.2.gz
ex_update.log
ex_update.log.1.gz
ex_update.log.2.gz
并被压缩到 exlogs.gz 中，如您所料，解压后它是一个包含所有原始文件的文件。有没有办法分离出原始的gz文件，以便它们可以正常解压缩而不是打印出二进制文件：
^_<8B>^H^H<9B>C<E8>a^@
^Cex_access.log.1^@<C4><FD><U+076E>-Kr<9D> <DE><F7>S<9C>^W<E8><CE><F0><FF><88>y[<D5><EA>+<A1>^EHuU<A8>^K<B6><94><AA>L4E^R̤^Z^B<EA><E1><DB>}<AE>̳<B6><D6>I<C6><F8><9C><DB><C6>
<F1>@G`<E6><D6><FE><E0>3<C2><C3>ٰ̆|<E4><FC><BB>#<FD><EE><B8>~9<EA>+<A7>W+<FF><FB><FF><F6><9F><FE><97><FF><E3><97><FF><FD>^Z<E3><FF><F8><E5><FF><FE><CB><C7><FF>Iy<FC>?<8E><F9>?<F3>?<EF><B5><F7><F9><BF><FF>ß<FF>
[etc]
是的，我可以再次收集日志（因为我确实有意识保持原件完好无损），但是获得访问服务器的批准是一件痛苦的事情，如果可能的话，我想避免它。
编辑：我使用的命令是
gzip -c ex_* > exlogs.gz
场景：单个 1g CSV.gz 正在写入 FTP 文件夹。同时，我的客户端机器通过 sFTP 连接到该文件夹并尝试将其拉下。
问：在获取该文件后，无论我在客户端获得任何明显的长度，都可以gzip -t检测到部分文件并使部分文件失败，而不管截断在哪里？
我认为当片段突然结束时，解压缩或 -t'esting 会在 99% 的可能截断点上出错，但是 gz 结构是否有干净的切割点，gzip 会意外报告成功？
不在桌面上的缓解措施（因为如果其中一个在起作用，我不需要问上面的问题。）
没有找到现有的 SO
一些 SO 涉及处理截断，但与需要在任何问题上可靠地使整个工作流程失败相比，它们处于有损可接受的上下文中。（我在医疗数据环境中进行计算，所以我宁愿让服务器停止并着火，也不愿传播不正确的统计数据。）
head并且没有涵盖“是否有可能出现误报？”
在 Linux Mint 20.2 Cinnamon 上，我想创建包含 Windows 10 的辅助磁盘驱动器 (SATA) 的磁盘映像，现在并不重要，直接gzip使用Parallel gzip=pigz编辑到 NTFS 格式的外部 HDD 上（即时压缩）。
我的问题是在生成的压缩文件中，内容的大小有些扭曲（错误），我希望您看看：
1TB 驱动器未压缩磁盘仅显示 3.8GB，而其压缩大小为 193 GB。
$ gzip --list sata-disk--windows10--2021-Sep-24.img.gz
compressed uncompressed ratio uncompressed_name
206222131640 3772473344 -5366.5% sata-disk--windows10--2021-Sep-24.img
-rwxrwxrwx 1 vlastimil vlastimil 193G 2021-Sep-24 sata-disk--windows10--2021-Sep-24.img.gz
序列号被删减，当然 ( ABCDEFGHIJKLMNO)
我试图用--sizeofpv命令强制大小
整个磁盘的确切字节大小来自smartctl -i /dev/sdX
dev=/dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_ABCDEFGHIJKLMNO; \
file=/media/vlastimil/4TB_Seagate_NTFS/Backups/sata-disk--windows10--"$(date +%Y-%b-%d)".img.gz; \
pv --size 1000204886016 < "$dev" | pigz -9 > "$file"
我很确定问题出在我如何使用管道或pv就此而言，但我无法证明这一点。使用常规文件 (~2GB) 的测试场景可以正常工作并且符合预期。这可能是一个错误gzip...？
请问我在这里做错了什么？先感谢您。
也许最后要介绍的是pvand的版本pigz：
我使用的是打包版本pv：1.6.6-1
我正在使用的编译版本pigz：2.6
我尝试从 Arxiv 下载一个压缩文件夹（ DVI 下的https://arxiv.org/format/math/0606086）
但它下载为 div.gz。我知道这是 TeX 输出。我尝试了 TeX 和各种解压缩应用程序，但它们都不起作用。我什至尝试重命名它以防万一出现错误。有什么建议么？如果这不是正确的地方，请随时删除。
我想修剪 gunzipped tarball 的路径，以便排除一些“虚假”的前导目录。让我用一个例子来解释。
我有以下目录结构，由tree命令输出：
tree /tmp/gzip-expt
/tmp/gzip-expt
├── gunzip-dir
├── gzip-dir
└── repo
└── src-tree
├── l1file.txt
└── sub-dir
└── l2file.txt
5 directories, 2 files
我想在 gzip-dir 中压缩 src-tree 所以这就是我要做的：
cd /tmp/gzip-expt/gzip-dir
tar -czvf file.tar.gz /tmp/gzip-expt/repo/src-tree
随后我在 gunzip-dir 中 gunzip file.tar.gz 所以这就是我所做的：
cd /tmp/gzip-expt/gunzip-dir
tar -xzvf /tmp/gzip-expt/gzip-dir/file.tar.gz
tree /tmp/gzip-expt/gunzip-dir显示以下输出：
/tmp/gzip-expt/gunzip-dir
└── tmp
└── gzip-expt
└── repo
└── src-tree
├── l1file.txt
└── sub-dir
└── l2file.txt
但是，我想tree /tmp/gzip-expt/gunzip-dir显示以下输出：
/tmp/gzip-expt/gunzip-dir
└── src-tree
├── l1file.txt
└── sub-dir
└── l2file.txt
换句话说，我不想看到路径的“虚假” tmp/gzip-expt/repo 部分。
我有一个包含数千个文件 .gz 的目录，我想解压缩并将解压缩的文件保存在特定目录中。
我已经尝试过，但我可以得到它（该领域的初学者）。
谢谢
我有几千个单独 GZip 压缩的文件（当然传递了-n标志，所以输出是确定性的）。然后他们进入一个 Git 存储库。我刚刚发现，对于其中 3 个文件，Gzip 在 macOS 和 Linux 上产生的输出不同。这是一个例子：
苹果系统
$ cat Engine/Extras/ThirdPartyNotUE/NoRedist/EnsureIT/9.7.0/bin/finalizer | shasum -a 256
0ac378465b576991e1c7323008efcade253ce1ab08145899139f11733187e455 -
$ cat Engine/Extras/ThirdPartyNotUE/NoRedist/EnsureIT/9.7.0/bin/finalizer | gzip --fast -n | shasum -a 256
6e145c6239e64b7e28f61cbab49caacbe0dae846ce33d539bf5c7f2761053712 -
$ cat Engine/Extras/ThirdPartyNotUE/NoRedist/EnsureIT/9.7.0/bin/finalizer | gzip -n | shasum -a 256
3562fd9f1d18d52e500619b4a5d5dfa709f5da8601b9dd64088fb5da8de7b281 -
$ gzip --version
Apple gzip 272.250.1
Linux
$ cat Engine/Extras/ThirdPartyNotUE/NoRedist/EnsureIT/9.7.0/bin/finalizer | shasum -a 256
0ac378465b576991e1c7323008efcade253ce1ab08145899139f11733187e455 -
$ cat Engine/Extras/ThirdPartyNotUE/NoRedist/EnsureIT/9.7.0/bin/finalizer | gzip --fast -n | shasum -a 256
10ac8b80af8d734ad3688aa6c7d9b582ab62cf7eda6bc1a0f08d6159cad96ddc -
$ cat Engine/Extras/ThirdPartyNotUE/NoRedist/EnsureIT/9.7.0/bin/finalizer | gzip -n | shasum -a 256
cbf249e3a35f62a4f3b13e2c91fe0161af5d96a58727d17cf7a62e0ac3806393 -
$ gzip --version
gzip 1.6
Copyright (C) 2007, 2010, 2011 Free Software Foundation, Inc.
Copyright (C) 1993 Jean-loup Gailly.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.
Written by Jean-loup Gailly.
这怎么可能？我认为 GZip 实现是完全标准的？
更新：为了确认 macOS 和 Linux 版本在大多数情况下确实产生相同的输出，两个操作系统都输出相同的哈希值：
$ echo "Vive la France" | gzip --fast -n | shasum -a 256
af842c0cb2dbf94ae19f31c55e05fa0e403b249c8faead413ac2fa5e9b854768 -
我正在寻找具有任意大字典（和“块大小”）的压缩工具。让我通过例子来解释。
首先让我们创建 32MB 的随机数据，然后将其连接到自身以生成长度为 64MB 的两倍长度的文件。
head -c32M /dev/urandom > test32.bin
cat test32.bin test32.bin > test64.bin
当然test32.bin不可压缩，因为它是随机的，但前半部分与后半部分test64.bin相同，所以它应该可以压缩大约 50%。
首先让我们尝试一些标准工具。test64.bin 的大小正好是 67108864。
我们从中了解到 gzip 和 bzip2 永远无法压缩此文件。但是，使用足够大的字典 xz 和 zstd 可以压缩文件，在这种情况下 zstd 做得最好。
但是，现在尝试：
head -c150M /dev/urandom > test150.bin
cat test150.bin test150.bin > test300.bin
test300.bin 的大小正好是 314572800。让我们在最高设置下再次尝试最好的压缩算法。
在这种情况下，这两种工具都无法压缩文件。
是否有一个工具具有任意大的字典大小以便它可以压缩诸如 test300.bin 之类的文件？
感谢评论和回答，事实证明 zstd 和 xz 都可以做到。但是，您需要 zstd 版本 1.4.x。
我尝试使用此命令压缩所有子目录中的所有 css 文件。
find . -iname "*.css*" -exec gzip -c '{}' > '{}'.gz \;
但它只会创建一个 {}.gz 文件。我最终使用了这个：
find . -iname "*.css" -exec sh -c "gzip -c '{}' > '{}'.gz" \;
效果很好。
问题是为什么第一个不起作用而第二个起作用？
注意：我可以很容易地使用 gzip -k 开关来保存源文件，但是 CentOS 7 上的 gzip 不支持它。