cmprss

状态：Alpha。 CLI 相对稳定，但可能存在错误，并且可能存在未来的破坏性更改。

命令行压缩多工具。用你记得住的名称替换 tar。 相关的XKCD。

当前支持

• bzip2
• gzip
• tar
• xz

用法

主要目标是根据输入推断行为，这样你就不需要记住复杂的 CLI 参数。

cmprss 支持对脚本中的输入和输出进行非常具体的说明，但在缺少信息的情况下也会表现得相当智能。

所有命令从左到右读取，输入始终来自 stdin 或指定的第一个文件名，输出是 stdout 或最后一个文件名/目录。

了解这些的最简单方法是查看一些示例

使用 gzip 压缩文件

cmprss file.txt file.txt.gz

将 2 个文件压缩到一个 tar 归档中

cmprss file1.txt file2.txt archive.tar

使用 xz 压缩 stdin

cat file.txt | cmprss file.xz

将 tar 归档解压到当前目录

cmprss archive.tar

解压 xz 压缩文件

cmprss file.xz file.txt

将 gzip 压缩文件解压到 stdout

cmprss file.txt.gz > file.txt

cmprss 目前不支持多级归档，如 .tar.gz，但它们可以通过管道轻松处理

cmprss tar uncompressed_dir | cmprss gz > out.tar.gz
cmprss gzip --extract out.tar.gz | cmprss tar -e output_dir

# Or a full roundtrip in one line
cmprss tar dir | cmprss gz | cmprss gz -e | cmprss tar -e

显式行为的示例

所有这些示例都适用于任何支持的压缩格式，前提是它们支持输入/输出格式。

如果省略输出文件名，cmprss 将尝试根据压缩类型推断文件名。

将文件/目录压缩到 tar 归档

cmprss tar filename # outputs to filename.tar
cmprss tar filename my_preferred_output_name.tar

将 2 个文件/目录压缩到 tar 归档

cmprss tar dir_1/ dir_2/ combined.tar
cmprss tar file_1.txt file_2.txt # outputs to file_1.txt.tar

解压 tar 归档

cmprss tar --extract archive.tar # extracts to the current directory
cmprss tar -e archive.tar custom_output_directory

cmprss 将检测 stdin 或 stdout 是否为管道，并在合适的位置使用这些进行输入/输出。

使用管道创建和提取 tar.gz 归档

cmprss tar directory | cmprss gzip > directory.tar.gz
cmprss gzip --extract directory.tar.gz | cmprss tar -e new_directory

# Or a full roundtrip in one line
cmprss tar directory_1/ directory_2/ | cmprss gzip | cmprss gzip -e | cmprss tar -e new_directory

贡献

开发环境

主要支持的开发环境定义在 flake.nix 文件中。这是一个 Nix Flake，它固定了 cmprss 所使用的所有软件包的版本。它包括一个 devShell，可以与 direnv 一起使用，每次进入目录时都可以使用工具。

尽管如此，cmprss 是一个非常标准的 Rust 应用程序，应该与最近的 Rust 工具链兼容。

CI 在稳定 Rust 工具链和固定的 Nix 版本上运行，以验证两者的正确性。

如果您在使用 Nix 环境或稳定 Rust 环境时遇到任何问题，请创建一个带有详细信息的 Github 问题。

常规提交

提交应遵循 常规提交 标准。

在 bin/commit.sh 中提供了一个帮助创建符合标准的提交的脚本，或者可以通过 task commit 使用。

测试覆盖率

鼓励改进测试覆盖率的 PR。

可以使用 cargo llvm-cov report 和 cargo tarpaulin 来衡量测试覆盖率。

@arcuru

我现在是唯一的开发者，我通常通过直接提交到 main 分支进行开发。对于较大的功能，我 可能 会通过 PR 运行 CI，以便有更多易于发现的特定功能文档。

一旦有人提交了非平凡的 PR 并提交了删除本 README 部分段落的请求，我将停止直接提交到 main。