Sublime Text不能直接运行Shell脚本，需通过配置自定义构建系统指定Bash解释器执行；核心是创建包含"cmd": ["bash", "$file"]等字段的JSON配置文件，并确保PATH环境变量和文件执行权限正确，以解决命令找不到或权限不足问题。
Sublime Text本身并不能直接“运行”Shell脚本，它只是一个强大的文本编辑器。我们之所以会觉得它“不能运行”，通常是因为没有正确配置它的“构建系统”（Build System），让它知道如何调用操作系统底层的Shell环境（比如Bash）去执行我们编写的脚本文件。它需要一个明确的指令，告诉它用哪个解释器、通过什么方式来执行当前文件。
要让Sublime Text顺利运行Shell脚本，核心在于创建一个自定义的构建系统，明确指示它调用Bash来执行你的脚本。这通常涉及到JSON格式的配置文件，指定执行命令和环境。
首先，在Sublime Text中，点击
Tools->
Build System->
New Build System...。 这会打开一个名为
untitled.sublime-build的新文件。你需要将以下JSON代码粘贴进去：
{
"cmd": ["bash", "$file"],
"file_regex": "^(.*?):([0-9]*):?([0-9]*)",
"selector": "source.shell",
"shell": false,
"working_dir": "$file_path",
"path": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" // 根据你的系统调整PATH
}简单解释一下：
"cmd": ["bash", "$file"]
：这是最关键的部分。它告诉Sublime Text，使用bash
命令来执行当前打开的文件（$file
是一个内置变量，代表当前文件的完整路径）。"selector": "source.shell"
：这个字段确保只有当你的文件被Sublime Text识别为Shell脚本（例如，.sh
文件）时，这个构建系统才会自动激活。"shell": false
：我们直接调用bash
，而不是通过一个中间的Shell层，这样更直接。"working_dir": "$file_path"
：将工作目录设置为当前文件所在的目录，这对于脚本内部引用相对路径的文件非常重要。"path": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
：这个很重要，尤其是在macOS或Linux上。Sublime Text启动时，它的环境PATH可能和你的终端里不一样。这里我们明确指定了Bash及其他常用命令的查找路径。你需要根据你自己的系统配置，确保bash
命令以及你的脚本可能调用的其他命令（如ls
,grep
,awk
等）都在这个PATH里。在macOS上，brew
安装的工具通常在/usr/local/bin
。在Windows上，如果你安装了WSL或Git Bash，路径配置会更复杂些，可能需要指向Git Bash的bin
目录，或者直接使用WSL的wsl.exe bash -c "..."
。
保存这个文件，你可以给它起一个有意义的名字，比如
Bash.sublime-build。 保存后，回到你的Shell脚本文件，点击
Tools->
Build System，选择你刚刚创建的
bash构建系统。 现在，当你按下
Ctrl+B(Windows/Linux) 或
Cmd+B(macOS) 时，Sublime Text就会尝试用Bash来执行你的脚本了。
Sublime Text构建系统的工作机制与常见误区
很多人初次接触Sublime Text运行脚本，可能会觉得它有点“怪”，不如直接在终端里敲命令那么直观。这其实是因为Sublime Text的“构建系统”和我们平时用的终端环境有着本质区别。它不是一个交互式Shell，而是一个执行特定命令的沙盒。
简单来说，Sublime Text的构建系统就是一套规则，告诉编辑器当用户触发“构建”操作时，应该执行什么外部命令。它能做的事情非常多，从编译C++代码、运行Python脚本到执行Shell命令，都可以通过配置实现。核心在于那个JSON文件，它定义了
cmd（要执行的命令）、
selector（激活条件）、
env（环境变量）、
path（命令查找路径）等等。
常见的误区在于，我们常常想当然地认为Sublime Text运行脚本时，会继承我们当前终端的所有环境变量。但事实并非如此。Sublime Text作为一个独立的应用程序，它启动时的环境变量可能非常“干净”，或者只继承了系统层面的基本变量，而不是你通过
.bashrc、
.zshrc等配置文件定制的那些。这就导致了脚本在终端能跑，但在Sublime里就报错“command not found”的问题。比如，你可能在脚本里调用了一个通过
nvm安装的Node.js命令，但Sublime Text的环境里并没有
nvm设置的
path。
另一个误区是，有人会尝试在
cmd里直接写复杂的Shell管道或逻辑。虽然
"shell": true可以启用一个中间Shell来解析这些，但我个人经验是，最好保持
cmd的简洁，直接调用解释器和脚本，复杂的逻辑留在脚本文件内部。这样更清晰，也更容易调试。如果非要执行复杂的单行命令，确保
"shell": true，并且注意引号和转义问题，那会是另一番折腾。
手把手：配置Bash脚本的Sublime Text构建系统
前面我们已经提供了一个基础的Bash构建系统配置，但实际使用中，你可能需要根据具体场景进行调整。
例如，如果你希望在脚本执行前进行一些预处理，或者传递特定的参数，
cmd字段可以更灵活。
假设你有一个Bash脚本，需要接收一个参数，比如一个文件名。你可以在构建系统中这样配置：
{
"cmd": ["bash", "$file", "my_argument_value"], // 传递一个固定参数
"file_regex": "^(.*?):([0-9]*):?([0-9]*)",
"selector": "source.shell",
"shell": false,
"working_dir": "$file_path",
"path": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
}这里
"my_argument_value"就是传递给脚本的第一个参数（
$1）。如果你想在运行时输入参数，那就需要更复杂的插件或者外部工具了，Sublime Text的构建系统本身不提供交互式输入。
再比如，如果你不希望每次都手动选择构建系统，而希望它能根据文件后缀自动切换，
selector字段就派上用场了。我们已经设置了
"selector": "source.shell"，这意味着只要Sublime Text识别出当前文件是Shell脚本（通常是
.sh后缀），这个构建系统就会被自动选中。你可以通过
View->
Syntax来查看当前文件的语法识别结果。
对于Windows用户，如果你使用Git Bash或者WSL（Windows Subsystem for Linux），配置会稍有不同。 Git Bash示例： 你需要找到Git Bash的
bash.exe路径，通常在
C:\Program Files\Git\bin\bash.exe。
{
"cmd": ["C:/Program Files/Git/bin/bash.exe", "$file"],
"file_regex": "^(.*?):([0-9]*):?([0-9]*)",
"selector": "source.shell",
"shell": false,
"working_dir": "$file_path",
"path": "C:/Program Files/Git/usr/bin;C:/Program Files/Git/bin" // 确保Git Bash的常用工具路径在内
}注意路径中的斜杠方向，JSON中通常使用正斜杠或双反斜杠。
WSL示例： 使用
wsl.exe来调用WSL内部的Bash。
{
"cmd": ["wsl.exe", "bash", "-c", "cd \"$(wslpath -u \"$file_path\")\" && bash \"$(wslpath -u \"$file\")\""],
"file_regex": "^(.*?):([0-9]*):?([0-9]*)",
"selector": "source.shell",
"shell": false,
"working_dir": "$file_path", // 这个working_dir可能需要通过wsl.exe内部的cd来控制
"path": "" // WSL内部有自己的PATH，这里可以留空或简化
}这里
"cd \"$(wslpath -u \"$file_path\")\" && bash \"$(wslpath -u \"$file\")\""是一个在WSL内部执行的命令串，
wslpath -u用于将Windows路径转换为WSL可识别的Linux路径，确保脚本在正确的目录下运行。
Shell脚本执行失败？Sublime Text中的环境路径与权限问题排查
当你在Sublime Text中运行Shell脚本遇到问题时，往往不是脚本本身语法错误，而是环境配置上的“绊脚石”。最常见的两个问题就是环境路径（PATH）和文件权限。
1. 环境路径（PATH）问题： 这是导致“command not found”错误的首要原因。就像我前面提到的，Sublime Text启动时获取的PATH变量可能和你终端里看到的不一样。
-
如何排查？
在你的Shell脚本里，加入一行
env
或者echo $PATH
，然后用Sublime Text运行这个脚本。输出结果会告诉你Sublime Text当前“看到”的PATH是什么。#!/bin/bash echo "Current PATH in Sublime Text: $PATH" # ... 你的脚本内容 ...
对比这个PATH和你终端里（
echo $PATH
）的PATH，你很可能会发现差异。如果你的脚本依赖某个特定命令（比如node
,python
,jq
等），而这些命令所在的目录不在Sublime Text的PATH中，那它就找不到。 -
解决方案：
在你的
.sublime-build
文件中，明确设置"path"
字段，将所有必要的目录都加进去。例如："path": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/homebrew/bin"
(macOS Homebrew路径) 或者，如果你的脚本只依赖少数几个命令，你可以在脚本内部通过完整的绝对路径来调用它们，比如"/usr/local/bin/node your_script.js"
，但这通常不是最佳实践，因为不够灵活。
2. 文件权限问题： 在Linux或macOS系统上，Shell脚本需要有执行权限才能被直接运行。如果一个脚本没有执行权限，即使Bash找到了它，也无法执行。
-
如何排查？
当你尝试运行一个没有执行权限的脚本时，Sublime Text的构建输出可能会显示“Permission denied”或类似的错误。你也可以在终端里用
ls -l your_script.sh
查看文件权限。 -
解决方案：
在终端里给你的脚本添加执行权限。
chmod +x your_script.sh
这通常只需要做一次。一旦脚本有了执行权限，Sublime Text通过Bash调用它时就不会再遇到权限问题了。
其他可能的坑：
-
编码问题： 如果你的脚本包含非ASCII字符，确保文件保存为UTF-8编码，并且脚本头部的
#!/bin/bash
后没有多余的空格或奇怪的字符。 - 脚本头部（Shebang）缺失或错误： 确保你的Shell脚本以`
