1. 从一次恼人的脚本报错说起那天下午我正在服务器上部署一个自动化任务脚本是从一个老项目里拷过来的看着挺简单。我习惯性地用sh deploy.sh命令执行结果终端立刻给我泼了一盆冷水./deploy.sh: 2: [[: not found脚本在第二行就卡壳了。我检查了一下第二行是一个再普通不过的条件判断if [[ “$ENV” “production” ]]; then。语法看起来没问题变量也定义了为什么[[:会“not found”呢这个错误信息乍一看很诡异它不是说语法错误而是说[[这个“命令”找不到。这让我瞬间意识到问题可能不在脚本本身而在执行它的那个“解释器”身上。这次经历也让我彻底搞清楚了bash和sh这对经常被混用的“兄弟”之间那些足以让你踩坑的微妙区别。如果你也在 Linux/Unix 环境或 macOS 的终端里折腾过脚本遇到过类似的“命令未找到”或者语法报错那这篇文章就是为你准备的。我们将不仅解决“[[: not found”这个具体问题更会深入幕后理解bash与sh的本质差异、Shebang 的作用以及如何写出兼容性更强的脚本。2. 错误根因[[是 bash 的“私房菜”sh 并不认识让我们直接切入核心。“[[: not found”这个错误的根本原因是执行脚本的解释器Shell不支持[[ ... ]]这种条件测试语法。[[ ... ]]是Bash (Bourne-Again SHell)引入的一个关键字keyword它比传统的[ ... ]这是一个命令实际上是test命令的别名功能更强大、更安全。例如在[[内部进行字符串比较时你可以直接使用、!并且不会因为变量未加引号或值为空而导致语法错误它还能支持正则表达式匹配~。然而sh通常不是一个独立的、功能固定的 Shell。在大多数现代 Linux 发行版和 macOS 上/bin/sh是一个指向其他 Shell 的符号链接symlink。常见的情况是在Debian/Ubuntu及其衍生系统上/bin/sh默认指向/bin/dashDebian Almquist Shell。在CentOS/RHEL/Fedora等系统上/bin/sh默认指向/bin/bash但 bash 在以sh身份被调用时会进入一种兼容模式posix mode。在macOS上/bin/sh是 BSD 版本的bashv3.2功能较老且同样有兼容性限制。无论是dash还是处于posix模式的bash它们的目标都是遵循POSIXPortable Operating System Interface标准。而[[ ... ]]是Bash 的扩展语法不属于 POSIX 标准。因此当你的脚本第一行没有指定解释器Shebang或者你直接用sh script.sh命令执行时系统就会调用那个 POSIX 兼容的sh来解释脚本。这个sh根本不认识[[这个“关键字”它试图把[[当作一个普通的命令去执行结果在系统的命令路径里当然找不到于是就报出了“[[: not found”。注意你可以通过ls -l /bin/sh命令查看它到底指向谁。例如输出lrwxrwxrwx 1 root root 4 Apr 5 10:00 /bin/sh - dash就明确表示sh是dash。所以解决方案的方向就很明确了要么让脚本用支持[[的 Shell 来运行即bash要么把脚本里的语法改成sh能认识的。3. 解决方案一修正执行方式——明确使用 bash这是最直接、最快的解决方法尤其适用于你临时需要运行一个别人的脚本或者你确认脚本就是为bash编写的。方法A在命令中显式指定 bash不要用sh your_script.sh而是用bash your_script.sh这样无论系统的sh指向谁都会强制使用bash解释器来执行整个脚本[[语法自然就能被识别。方法B直接执行脚本需要可执行权限首先给脚本添加可执行权限chmod x your_script.sh然后直接通过路径执行./your_script.sh但是这个方法生效的前提是脚本文件的第一行包含了正确的 Shebang如果脚本第一行是#!/bin/bash或#!/usr/bin/env bash那么当你执行./your_script.sh时系统内核会读取这第一行然后调用/bin/bash来执行这个脚本。如果脚本没有 Shebang 行系统可能会使用默认的 Shell可能是你的登录 Shell也可能是sh来执行结果可能再次失败。方法C使用 source 或点命令source your_script.sh # 或者 . your_script.sh这种方式会在当前 Shell 进程中执行脚本中的命令。如果你的当前终端本身就是bash那么脚本中的bash语法包括[[也能正常工作。但要注意这种方式下脚本中定义的变量和函数会在执行后保留在当前 Shell 环境中可能会造成“污染”。实操心得对于一次性执行bash script.sh是最稳妥的。对于准备长期使用的脚本务必加上 Shebang并赋予可执行权限然后用./script.sh方式执行这是最规范的做法。使用source要小心特别是脚本里有cd、exit或变量修改时可能会意外改变你当前的工作环境。4. 解决方案二修改脚本本身——提升兼容性如果你希望你的脚本能在更广泛的环境比如默认使用dash的系统中不加修改地运行或者你遵循严格的 POSIX 兼容性要求那么修改脚本内部的语法是根本之道。核心就是把[[ ... ]]替换成 POSIX 兼容的写法。1. 字符串比较Bash 写法if [[ “$var” “value” ]]; thenPOSIX 兼容写法if [ “$var” “value” ]; then注意这里用的是单个等号并且[后和]前必须有空格它是一个命令。强烈建议变量始终用双引号包裹如“$var”这样可以防止变量值为空或包含空格时导致语法错误。这是编写健壮 Shell 脚本的黄金法则之一。2. 数值比较Bash 写法if [[ $num -gt 10 ]]; then(也可以用(( $num 10 )))POSIX 兼容写法if [ $num -gt 10 ]; then在[ ]中必须使用-eq,-ne,-gt,-lt,-ge,-le这些参数进行比较。3. 正则表达式匹配Bash 写法if [[ “$str” ~ ^prefix.* ]]; thenPOSIX 兼容写法没有直接等价物。通常需要借助外部命令expr或grepif echo “$str” | grep -q ‘^prefix.*’; then # 或者 if expr “$str” : ‘^prefix.*’ /dev/null; then4. 复杂逻辑组合Bash 写法if [[ -f “$file” ( “$mode” “read” || “$mode” “write” ) ]]; thenPOSIX 兼容写法if [ -f “$file” ] { [ “$mode” “read” ] || [ “$mode” “write” ]; }; then注意[ ]中的-a(and) 和-o(or) 运算符已被标记为“过时”在不同系统中行为可能不一致。最可靠的做法是使用 Shell 的和||来连接多个独立的[ ... ]测试命令。一个完整的修改示例 假设原 bash 脚本片段如下#!/bin/bash if [[ “$USER” “root” ]]; then echo “Running as root, be careful!” elif [[ -d “/data” -w “/data” ]]; then echo “Data directory is accessible.” fi修改为 POSIX 兼容版本#!/bin/sh if [ “$USER” “root” ]; then echo “Running as root, be careful!” elif [ -d “/data” ] [ -w “/data” ]; then echo “Data directory is accessible.” fi注意Shebang 也改成了#!/bin/sh这明确宣告了本脚本的兼容性目标。避坑指南使用[ ]时每个[和]前后都必须有空格因为它们本质上是命令名和它的参数。使用(( ))进行算术运算和比较是bash的特性sh不支持。应改为$(( ))进行算术扩展或使用expr命令。数组 (array(a b c)) 和关联数组也是bash的扩展在严格 POSIXsh中不可用。5. Shebang 的奥秘脚本的第一道指令Shebang#!是脚本魔法开始的地方。它出现在脚本文件的第一行告诉系统应该用哪个解释器来执行这个文件。正确的 Shebang 写法#!/bin/bash明确要求使用系统/bin目录下的bash。这是最直接的方式但假设了bash一定在那个路径。#!/usr/bin/env bash更推荐的方式。它利用env命令在系统的PATH环境变量中查找bash的位置。这提高了脚本的可移植性特别是在那些bash可能安装在/usr/local/bin或其他非标准路径的系统如 macOS 通过 Homebrew 安装的较新版本 bash上。Shebang 如何工作当你输入./script.sh并回车后系统内核识别到这是一个可执行文件。内核读取文件的前两个字节如果发现是#!它就会把这一行剩余的部分当作解释器路径。内核启动这个解释器例如/bin/bash并将脚本文件的路径作为参数传递给解释器。bash被启动然后读取并执行script.sh文件中的命令。如果没有 Shebang 会怎样如果脚本文件没有 Shebang并且你以./script.sh方式执行那么不同的系统行为可能不同。通常现代系统会默认使用/bin/sh来执行。这也就是为什么你的脚本里写了[[直接./执行也可能报错的原因——如果系统默认sh是dash的话。实操建议为每一个脚本都写上 Shebang这是好习惯。如果你主要用bash的特性用#!/usr/bin/env bash。如果你追求最大兼容性并确保脚本只使用 POSIX 特性用#!/bin/sh。Shebang 必须是文件的绝对第一行前面不能有任何空格或空行。6. 环境变量与执行上下文为什么有时能过有时不行你可能会遇到一种情况在终端里手动一行行输入脚本内容包括[[ ... ]]能成功但把同样的内容保存成脚本用sh执行就报错。这涉及到执行上下文的不同。交互式 Shell (Interactive Shell) vs 非交互式 Shell (Non-interactive Shell)当你打开一个终端窗口你进入的是一个交互式 Shell。它可以显示提示符接受用户输入通常还支持命令行编辑、历史、作业控制等高级功能。当你执行一个脚本文件时系统启动的是一个非交互式 Shell。它只负责读取文件并执行命令没有用户交互界面。登录 Shell (Login Shell) vs 非登录 Shell (Non-login Shell)登录 Shell 是你登录系统时启动的第一个 Shell例如通过 ssh 登录或 tty 登录。它会读取特定的配置文件如~/.bash_profile,~/.profile。非登录 Shell 是在登录后启动的 Shell例如在终端里再输入bash或者执行脚本。它读取的配置文件可能不同如~/.bashrc。关键在于不同的启动模式Shell 可能会加载不同的配置文件并可能设置不同的默认选项和兼容性模式。例如你的交互式终端很可能就是bash并且加载了~/.bashrc其中没有设置 POSIX 模式。所以你在里面直接输入[[命令bash会以其完整的扩展模式运行一切正常。但当你用sh script.sh执行时你启动的是一个非交互、非登录的sh可能是dash或者是bash的 POSIX 兼容模式。这个环境是“纯净”且受限的自然就不支持[[。你可以通过一个简单的命令来验证你当前 Shell 和脚本执行环境的区别 在终端输入echo $0这通常会输出-bash或bash表示当前是交互式bash。 在脚本test.sh里写#!/bin/sh echo “Script shell: $0”然后执行sh test.sh输出很可能是sh证实了执行环境的不同。7. 高级排查与兼容性实践理解了原理我们就能进行更系统化的排查和设计。1. 如何检查脚本的语法兼容性有一个强大的工具叫shellcheck。它是一个静态分析工具可以检查 Shell 脚本中的错误、不规范的写法以及兼容性问题。 安装以 Ubuntu 为例sudo apt-get install shellcheck使用shellcheck your_script.sh它会明确指出哪里使用了非 POSIX 的语法比如[[并给出修改建议。对于编写健壮、可移植的脚本来说shellcheck是必备神器。2. 在脚本内部进行 Shell 检测如果你必须使用某些bash特性但又希望脚本在不小心被sh调用时能给出友好提示可以在脚本开头加入检测#!/usr/bin/env bash # 检测当前运行的 Shell 是否是 bash if [ -z “$BASH_VERSION” ]; then echo “错误此脚本需要使用 Bash 来运行。” 2 echo “请使用命令 ‘bash $0’ 来执行。” 2 exit 1 fi # 或者检测是否支持 [[ 语法更具体 if ! ( eval ‘[[ 1 -eq 1 ]]’ ) /dev/null 21; then echo “错误当前 Shell 不支持 [[ ... ]] 语法请使用 Bash。” 2 exit 1 fi3. 编写兼容性脚本的最佳实践Shebang 明确化根据你的目标选择#!/bin/shPOSIX或#!/usr/bin/env bashBash。引用所有变量总是使用“$var”除非你有明确的理由不这样做比如进行单词分割。使用printf代替echoecho的行为在不同 Shell 中略有差异printf则更一致、更强大。避免使用 Bashisms除非你确定脚本只在bash环境中运行否则避免使用[[ ]]、(( ))、数组、{a..z}扩展、重定向等特性。使用set -euo pipefail在脚本开头加上这行对于bash脚本可以让脚本在遇到错误命令失败、变量未定义、管道中任意命令失败时立即退出有助于写出更安全的脚本。注意pipefail可能不是所有sh都支持。代码清晰优先有时为了兼容性多写几行清晰的[ ]测试比用精巧但晦涩的bash特性更好维护。8. 从网络热词看常见脚本执行场景的坑结合你提供的网络热词我们可以看到大量与脚本执行相关的困惑很多都直接或间接与 Shell 环境有关。curl -fsSL https://ollama.com/install.sh | sh这是一个非常常见的安装命令模式。它从网络下载脚本并直接通过管道传递给sh执行。这里潜藏的风险是你完全信任远程脚本会用sh兼容的语法编写。如果那个install.sh脚本内部包含了[[等bash语法而你的系统sh是dash那么下载后执行就会立刻报错。安全建议对于来源不明的脚本最好先下载下来 (curl -O)检查一下内容特别是 Shebang 和语法再决定如何执行。-bash: nginx: command not found/-bash: docker: command not found这类错误看似与bash/sh无关但根源在于环境变量PATH。当你在交互式bash-bash提示了这一点中输入命令时bash会去PATH列出的目录里查找可执行文件。如果命令没安装或者安装路径不在PATH中就会报此错。这提醒我们在脚本中执行外部命令时也不能假设PATH和你的交互式 Shell 一样。在脚本开头显式设置关键路径或使用命令的绝对路径是更稳妥的做法。Git Bash 相关Git Bash 是 Windows 上的一个模拟 Linux 环境的终端它自带了一个bash。在 Git Bash 中执行脚本其行为类似于 Linux 下的bash。但如果你在 Git Bash 里用sh命令它调用的可能是一个更精简的、模拟sh的环境同样可能遇到兼容性问题。理解你所在的环境到底是哪种 Shell 至关重要。编码问题 (bash 终端本身是 utf-8 的, gbk 输出无法正常渲染)这虽然是显示问题但也属于执行环境配置的一部分。脚本如果输出非 UTF-8 编码的内容在 UTF-8 终端里就会乱码。在编写跨环境脚本时考虑文本编码也是一个好习惯。解决“[[: not found”这个具体错误并不难但通过它我们窥见了 Shell 脚本世界里关于兼容性、可移植性和环境差异的冰山一角。核心在于养成好习惯明确 Shebang、理解执行环境、谨慎使用 Shell 特性、多用工具检查。下次再遇到类似的“命令未找到”错误时先别急着怀疑脚本问问自己“现在到底是哪个 Shell 在给我干活”