sublime构建系统不能直接使用shell alias，因其运行时不加载~/.zshrc等配置文件，alias在非交互式shell中不可见；应改用绝对路径、封装脚本或项目级构建系统配置。
Sublime构建系统里不能直接用shell alias
构建系统（.sublime-build）运行时**不加载你的 shell 配置文件**（如 ~/.zshrc 或 ~/.bashrc），所以你在终端里定义的 alias st="sublime_text" 在 Ctrl+B 里完全不可见、不会展开。这不是 Sublime 的 bug，而是进程环境隔离导致的——它启动的是一个干净的子进程，没 source 任何 rc 文件。
常见错误现象："cmd": ["st", "$file"] 报错 /bin/sh: st: command not found，或静默失败；"shell_cmd": "st $file" 同样失效。
- 别在
cmd数组里写别名，它只认真实可执行路径或 PATH 中存在的命令 -
shell_cmd走的是系统 shell（/bin/sh），但 alias 是交互式 shell 特性，非交互 shell 默认不启用 alias - 即使加
"shell": true，也需显式启用 alias 支持（比如bash -i -c "st $file"），但这么做不可靠、跨平台差、还慢
想复用终端 alias？改用绝对路径或封装脚本
最稳的方式是绕过 alias，直击本质：alias 指向的到底是什么？找到它，填进构建系统。
在终端执行：which sublime_text（Linux/macOS）或 where sublime_text（Windows），拿到真实路径。例如：
"cmd": ["/opt/sublime_text/sublime_text", "$file"]
如果 alias 指向的是包装逻辑（比如自动选 workspace、加参数），那就把它写成独立脚本：
- 新建
~/bin/st-project（确保~/bin在 PATH 中） - 内容示例（bash）：
#!/bin/bash exec /opt/sublime_text/sublime_text --project "$1" "$2"
-
chmod +x ~/bin/st-project，然后构建系统里写："cmd": ["st-project", "$project_path"]
项目级构建系统中调用别名？用 shell_cmd + 显式 shell
仅当必须依赖 alias 且无法改脚本时，可强制唤起交互式 shell，但仅限 macOS/Linux，且要承担兼容性风险：
"shell_cmd": "bash -i -c 'st $file'", "shell": true
注意几个坑：
-
-i会让 bash 加载~/.bashrc，但可能卡住（等待 stdin）；加-c后需确保 alias 已在该文件中定义（不是~/.bash_profile） - Zsh 用户得换
zsh -i -c，且 alias 必须在~/.zshrc中 - Windows 不支持这种模式，PowerShell 的
Invoke-Expression也不等价 - 每次构建都启一个交互 shell，性能差，且
$file等变量需被 shell 二次展开，容易引号逃逸出错
真正需要“别名效果”？用项目配置或 Build System name
很多人所谓“设置别名”，其实是想让不同项目跑不同命令，或让菜单里显示更易懂的名字——这根本不需要碰 shell alias。
- 菜单中显示名称由构建系统 JSON 的
"name"字段控制，比如"name": "Run Flask Dev Server"，和 alias 无关 - 项目专属命令直接写进
.sublime-project的build_systems字段，每个项目互不影响 - 想一键启动带参数的 Python 服务？直接写：
"cmd": ["python", "-m", "flask", "run", "--port=5001"] - 需要区分环境？建两个构建系统：
"name": "Test Env"和"name": "Prod Env"，对应不同cmd和working_dir
真正的麻烦点往往不在“怎么写 alias”，而在于混淆了终端交互环境和构建系统执行环境——前者是你日常敲命令的地方，后者是 Sublime fork 出来的、干净但受限的子进程。盯住路径、变量作用域、shell 类型这三点，比硬塞 alias 可靠得多。
