必须显式调用sh或bash解释器，如"cmd": ["bash", "$file"]，并设"working_dir": "$file_path"确保正确路径和环境。
Build System里怎么写才能调用Shell脚本而不是直接执行代码
Sublime的Build System默认不支持直接运行.sh文件，它会把文件内容当成命令传给shell，导致语法错误或权限拒绝。关键不是“能不能跑”，而是“以什么身份、在什么路径、带什么环境变量去跑”。
实操建议：
- 必须显式调用
sh或bash，比如"cmd": ["bash", "$file"]，不能只写"cmd": ["$file"] -
$file是完整路径，如果脚本依赖同目录下的其他文件（如config.ini），得确保工作目录正确——用"working_dir": "$file_path"强制切到脚本所在目录 - Windows下若用Git Bash，路径可能含空格或中文，
bash命令要加-l参数加载登录环境，并用"cmd": ["C:\Program Files\Git\bin\bash.exe", "-l", "-c", "source "$1"; exec bash", "_", "$file"]这种绕法
如何让Build System自动识别并运行不同后缀的Shell脚本
一个Build System通常只绑定一种语法高亮（如ShellScript），但实际项目里可能混用.sh、.bash甚至无后缀的可执行脚本。Sublime不会自动按文件权限判断是否可执行，得靠selector和file_extensions手动覆盖。
实操建议：
- 在Build System配置里加
"file_extensions": ["sh", "bash", "deploy", "ci"]，把自定义脚本后缀全列进去 - 如果脚本没后缀但有
#!/bin/bash头，靠selector匹配更可靠："selector": "source.shell | source.bash"，前提是文件已用Shell语法高亮打开 - 避免用
"selector": "text.plain"——这会让所有纯文本文件触发构建，极易误触
为什么脚本里cd ..或source ./env.sh总失败
Build System启动的子进程默认不继承当前终端的环境，也不读取~/.bashrc，所以source找不到路径、cd报错“no such file or directory”很常见。根本原因是工作目录和环境变量都受限。
实操建议：
- 绝对路径优先：把
source ./env.sh改成source "$file_path/env.sh"，cd ..换成cd "$file_path/.." - 需要加载用户环境时，在
cmd里包装一层："cmd": ["bash", "-i", "-c", "source ~/.bashrc && cd $file_path && bash $file"]，但注意-i会变慢，且某些服务器禁用交互式shell - 敏感操作（如
sudo）无法静默执行，Build System弹不出密码输入框，这类脚本必须提前配置免密或改用pkexec等替代方案
调试Build System输出乱码或卡死的快速定位法
Sublime构建面板显示[Finished in 0.1s]但没输出，或中文变成，通常不是脚本问题，而是编码或缓冲区截断。Build System底层用的是Python的subprocess.Popen，对stderr/stdout处理很朴素。
实操建议：
- 加
"quiet": false确保所有输出都进面板；加"shell": true让命令走/bin/sh -c（注意：这会改变变量展开行为） - 中文乱码时，在脚本开头加
export LANG=en_US.UTF-8或export PYTHONIOENCODING=utf-8，比改Sublime设置更直接 - 卡死多半是脚本在等stdin（比如
read -p），Build System不提供交互式输入流，必须删掉或用echo "default" | your_script.sh模拟
真正麻烦的是跨平台路径拼接和环境隔离——同一份.sublime-build文件在Mac和Linux上可能因/bin/bash路径差异或sed参数不同而失效，别图省事共用一个配置。
