shc（“通用 Shell 脚本编译器”）可以把一个 Shell 脚本变成独立的可执行文件。这个名字很容易让人误会：脚本的逻辑会被翻译成机器码，就像 C 编译器把 .c 文件变成原生指令一样。这个假设是错的，而 shc 听起来在做的事、和它实际做的事之间的落差，正好可以说明该怎么正确使用它，以及为什么它藏不住任何想把内容取出来的人。
1. SHC 实际上做了什么
shc 完全没有编译 Shell 逻辑。它会写出一份 C 源代码，把你原本的脚本内容以密文形式嵌进去，再加上一小段运行期程序，负责把密文解密回一个临时文件，然后通过脚本 shebang 那一行指定的解释器（/bin/sh、/bin/bash 等）去执行这个临时文件。真正被 C 编译器（cc）编译的，是这个外壳程序，这也是为什么输出结果是货真价实的 ELF 可执行文件，看起来完全没有 .sh 的痕迹。
加密方式是 RC4（ARC4）流密码的一个变体。每次运行 shc，它都会生成一组全新的 256 字节随机密钥，把密钥和密文一起烘进同一个可执行文件里。这整个过程完全不会检视脚本的控制流程、不会解析变量，也不会把任何指令变成机器指令——解释器最终解析、执行的还是同一段文字，只是来源从 myscript.sh 换成了一个临时文件而已。
1.1 是遮蔽，不是编译
这个区别很重要，因为”编译”这个词会带来一些在 shc 身上完全不成立的预期。真正的编译器——交叉编译入门文章讲的就是这种编译器——会把源代码翻译成特定目标指令集的指令，产出的可执行文件里不会再留下任何形式的源代码。shc 的可执行文件则完整保留了你整份脚本，一个字节都没少，只是被一把随身携带的密钥锁在密文后面。把输出文件从 .sh 改名成 .x，改变的只是调用方式，不会改变实际执行的内容。
2. 安装 SHC
多数发行版的软件包仓库都能直接安装 shc：
sudo apt install shc # Debian、Ubuntu
sudo dnf install shc # Fedora、RHEL如果你的发行版没有这个软件包，源代码是一个很小的 C 项目，可以直接克隆下来用 make 构建——除了标准 C 工具链之外没有其他外部库依赖。
3. 编译与运行脚本
假设有一份脚本 deploy.sh：
shc -f deploy.sh这会生成两个新文件：deploy.sh.x，也就是你实际要运行的可执行文件；以及 deploy.sh.x.c，shc 用来编译出可执行文件的那份 C 源代码。两者都含有你脚本的加密内容，所以 .c 文件也该和可执行文件一样小心对待——编译完就删掉它，连同原本的 deploy.sh 一起删除，才算真正做到这件事的目的：
rm deploy.sh deploy.sh.x.c
./deploy.sh.x3.1 常用参数
除了 -f 之外，以下几个参数涵盖了大多数实际用法：
-o outfile：自定义可执行文件名称，取代默认的<script>.x。-e dd/mm/yyyy：让可执行文件在指定日期之后拒绝运行，适合试用或演示用的脚本。-x command：以printf格式自定义调用解释器的命令，供需要非标准执行参数的脚本使用。
3.2 让可执行文件能搬到别的机器上运行
shc 默认编译出来的可执行文件，只保证在编译它的那台机器上正常运行。把它复制到别的主机，可能直接跑不动，也可能行为异常——第一次遇到时，很容易误以为是打包出了问题。其实不是，这是刻意的限制。编译时加上 -r 就能解除这个限制：
shc -r -f deploy.sh只要可执行文件要在编译它的机器以外的地方运行，几乎就是实际部署的常态，这时就该用 -r。
4. 为什么这种加密保护不了机密
shc 自己的文档也明确写着它是遮蔽工具，不是安全工具，而它的运行机制正好解释了原因。用来加密脚本的随机密钥，就和它要解密的密文放在同一个可执行文件里——要还原出可用的明文，只需要从可执行文件中把密钥找出来，再照着可执行文件启动时自己做的解密步骤重做一次即可。已经有公开工具在自动化做这件事。RC4 系列密码本身就被认为强度不足（因此在 TLS 中被禁用），但就算换成强度更高的密码，只要密钥和密文放在一起，一样防不住任何人——没有任何密码算法能在密钥随货附送的情况下保护数据。
如果你的脚本里有真正的机密——API 令牌、数据库密码、私钥——shc 藏不住这些东西，藏不过任何有心人。它顶多能挡住那种纯粹出于好奇、打开文本编辑器看一眼的人，门槛低得多。
5. 什么时候该用 SHC，什么时候不该
如果目的是防止别人随手查看或修改脚本，shc 是合理的选择：把内部工具发给不懂技术、可能手痒想”调整”一下的用户，或者需要交付的东西看起来、用起来都得像个可执行文件，而不是一眼就看得出可以编辑的脚本。任何要离开构建机器的可执行文件都该搭配 -r；过期日期参数则只该当成演示用的小功能，不要当成访问控制手段——用户调整系统时间的难度，并不会比把密钥取出来高多少。
但只要真正的需求是要防范有能力的攻击者，shc 就是用错工具了。那种需求该交给真正的机密管理机制——部署时注入的环境变量、机密管理系统，或是脚本运行机器上的文件权限与访问控制——而不是交给一支自己随身带着钥匙的脚本。