使用 VSCode 写 shell 脚本指南（Bourne Shell 和 C Shell，Bash 和 Dash 的核心区别）

Irene19912026-06-21 8:28

本文是一份VSCode编写Shell脚本的实用指南，主要包含以下内容：

  • 基础使用
  • 创建.sh文件自动识别为Shell脚本
  • 两种运行方式：终端执行或右键运行（需插件）
  • 核心工具推荐
  • ShellCheck：语法检查和错误提示
  • BashIDE：代码补全和调试功能
  • CodeRunner：一键运行脚本
  • shell-format：自动格式化代码
  • 配置优化
  • 设置默认Shell解释器路径
  • 开启保存时自动检查和格式化
  • 常见问题解决
  • 终端乱码问题的排查与修复
  • 不同操作系统下的编码设置
  • CodeRunner插件配置方法
  • 实用技巧
  • 快速注释多行代码
  • 使用脚本模板
  • 大纲视图跳转函数定义

指南特别针对Windows用户提供了GitBash路径设置方案，并对比了VSCode与vi/vim等编辑器的优劣势，适合大数据开发场景下的Shell脚本编写需求。

使用 VSCode 写 shell 脚本指南

VSCode 是一个非常优秀的 Shell 脚本开发工具，而且比你想象的更强大。

✅ 基础用法

  1. 创建文件 ：新建 .sh 文件，VSCode 会自动识别为 Shell 脚本。

  2. 编写脚本 ：正常写 #!/bin/bash 开头的代码。

  3. 运行脚本：

    • 方式一：在终端执行 bash your_script.sh

    • 方式二：右键文件 → "在终端中运行"（需安装插件）

🔧 推荐插件（大幅提升体验）

插件名称 作用
ShellCheck 静态语法检查，高亮错误和潜在问题（强烈推荐）
Bash IDE / Bash Debug 语法高亮、代码补全、跳转定义、甚至断点调试
Code Runner 一键运行当前脚本文件，无需手动切终端
shell-format 自动格式化 Shell 代码（缩进、对齐）

💡 实用配置

在 VSCode 的 settings.json 中添加：

json

javascript 复制代码 
{
  // 默认 Shell 解释器路径
  "terminal.integrated.defaultProfile.linux": "bash",
  // 保存时自动运行 ShellCheck 检查
  "shellcheck.enable": true,
  // 自动格式化保存
  "editor.formatOnSave": true
}

🆚 与专用编辑器的对比

维度 VSCode vi / vim 专业的 Shell 编辑器
上手难度 低（图形化） 高（需记忆快捷键） 中等
调试支持 有插件可断点调试 基本无 强（如 JetBrains 系列）
扩展生态 极丰富 有限 专一但强大
跨平台 完美支持 支持 主流平台支持

结论：对于大数据开发场景（写 ETL 调度脚本、数据处理脚本），VSCode + ShellCheck + Bash IDE 的组合已经足够满足 95% 的需求，而且比 vi 更高效，比商业 IDE 更轻量。

创建Shell脚本

bash 复制代码 
#!/bin/bash
echo "Hello, VSCode!"
echo "当前路径: $(pwd)"

运行脚本（三种方式）

方式一：用 Code Runner 一键运行（推荐新手）

  • 打开 hello.sh，点击右上角的 ▶ 运行 小三角

  • 下方终端会自动弹出并显示结果

方式二：手动在终端运行

  • 按 ```Ctrl + ````` 打开终端

  • 输入：

bash

复制代码 
bash hello.sh

方式三：先给权限再运行（真实生产环境常用）

bash

复制代码 
chmod +x hello.sh   # 给执行权限（只需一次）
./hello.sh          # 直接运行

🧠 几个让你效率翻倍的技巧

技巧 操作
自动格式化 按 Shift+Alt+F，代码瞬间对齐（需装 shell-format）
快速注释多行 选中多行按 Ctrl+/
侧边栏显示大纲 点击左侧大纲图标，快速跳转到函数定义
全局搜索 Ctrl+Shift+F，搜索所有脚本文件中的内容
脚本模板 新建 .sh 文件时，输入 ! 然后按 Tab，自动生成 #!/bin/bash 头

🔧 （可选）：打开自动检查功能

让VSCode在你写代码时就提示语法错误：

在 settings.json 中添加：

json

javascript 复制代码 
{
  "shellcheck.enable": true,
  "editor.formatOnSave": true,
  "[shellscript]": {
    "editor.defaultFormatter": "foxundermoon.shell-format"
  }
}

怎么打开 settings.json？

  • 按 Ctrl+Shift+P → 输入 Preferences: Open Settings (JSON) → 粘贴进去保存

📝 一个实战小练习

写一个脚本 check_cpu.sh，内容如下：

bash

bash 复制代码 
#!/bin/bash
# 打印当前CPU使用率

echo "=== 当前CPU信息 ==="
# 使用top命令，取第一行CPU信息（macOS/Linux通用）
top -l 1 | grep "CPU usage" 2>/dev/null || top -bn1 | grep "Cpu(s)"

运行后，你应该能看到类似 CPU usage: 12.5% user, 8.3% sys, 79.2% idle 的输出。

🆚 和 vi / 记事本对比

体验 VSCode vi/vim 记事本
语法高亮 ✅ ✅ ❌
实时检查 ✅（ShellCheck） ❌ ❌
一键运行 ✅ 需切终端 ❌
格式化代码 ✅ 需配置 ❌
学习成本 低 高 低但功能缺失

shell脚本，运行后 终端输出乱码了

这种情况很常见，通常就是字符编码不对付。解决思路很简单：先让终端和脚本的"语言"统一，再排查特殊字符。

🔧 快速排查与解决（分步走）

  1. 临时指定编码运行：这是最快的方法，可以绕过脚本当前的编码问题。

    bash

    复制代码 
    # 强制使用 UTF-8 运行脚本
LANG=en_US.UTF-8 bash your_script.sh

    如果你用的是 Windows 的 Git Bash，也可以先执行 chcp 65001 把终端切到 UTF-8 再运行脚本。

  2. 检查并转换脚本文件编码 ：在 VSCode 的右下角能看到当前文件编码，点一下可以选"通过编码重新打开"，然后选 UTF-8 。如果还是有乱码，可以尝试选 GB2312 或 GBK，这通常是中文 Windows 环境下旧脚本用的编码。

  3. 检查你的脚本内容 ：尤其要注意脚本里是否有从网页、文档复制过来的特殊符号，比如中文引号 " " 或长连接符 ---，它们很容易被终端误解。最好把它们都替换成标准的英文符号。

🐧 关于终端环境的一点补充

  • Windows (CMD/PowerShell) ：默认编码通常是 GBK，如果脚本是 UTF-8，中文就会乱码。解决办法是改用 Git Bash 或 WSL，它们原生支持 UTF-8。

  • macOS / Linux：默认就是 UTF-8，基本不会有问题。如果遇到乱码，大概率是脚本本身编码不是 UTF-8。

  • 没有 root 权限？ ：也可以把编码设置写在 ~/.bashrc 或 ~/.zshrc 里，让你自己的终端环境永久生效：

    bash

    复制代码 
    export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8

    之后重新打开终端即可。

💡 怎么确认问题源头？

你可以做个简单测试，看看到底是终端本身的问题，还是脚本的问题：

  1. 在终端里直接输入 echo "你好" 并回车。

  2. 如果输出乱码：说明是终端本身的编码设置不对，需要调整终端的语言环境（参考上面的补充）。

  3. 如果输出正常：那就说明是脚本文件的编码不对，按第2步在 VSCode 里重新转换一下编码保存即可。

你先试试这几个方法，如果还有问题，可以把你的操作系统 （Windows/Mac/Linux）和终端类型 （CMD/Git Bash/PowerShell）以及脚本里输出的中文内容发给我，我帮你进一步定位。

看到文件编码是 UTF-8 ，说明你的脚本文件本身没问题。问题大概率出在终端的编码设置上。

🎯 快速定位：先跑一个最简单的测试

在 VSCode 的终端里执行以下命令，确认终端的编码环境：

bash

复制代码 
echo $LANG

  • 如果返回结果包含 UTF-8（比如 en_US.UTF-8），说明终端编码正确。

  • 如果返回结果为空或不是 UTF-8，说明终端环境需要调整。

🔧 解决方案（根据你的操作系统）

方案一：macOS / Linux（默认 UTF-8）

直接在终端执行，临时生效（仅本次会话）：

bash

复制代码 
export LANG=en_US.UTF-8
bash your_script.sh

如果想永久生效 ，把这个命令加到 ~/.bashrc（或 ~/.zshrc，如果你用 Zsh）：

bash

复制代码 
echo 'export LANG=en_US.UTF-8' >> ~/.bashrc
source ~/.bashrc

方案二：Windows（常见坑）

如果你用的是 CMD 或 PowerShell：

  1. 先执行 chcp 65001 把终端切到 UTF-8 编码。

  2. 再执行 bash your_script.sh。

如果你用的是 Git Bash 或 WSL：

  • 右键窗口标题 → 选项 → 字体 → 选择支持中文的字体（如 Consolas 或 新宋体）。

  • 同时检查 echo $LANG，如果为空，参考方案一的永久设置方式。

💡 为什么 VSCode 显示 UTF-8，但终端还是乱码？

VSCode 编辑器和终端是两个独立组件：

  • 编辑器：用 UTF-8 编码正确保存了文件。

  • 终端：可能沿用了操作系统的默认编码（Windows 上是 GBK，macOS/Linux 上是 UTF-8）。

当终端用 GBK 去解析 UTF-8 编码的中文时，就会出现乱码。所以你需要让终端的编码和文件保持一致（都是 UTF-8）。

✅ 验证方法

改完后，在终端执行：

bash

复制代码 
echo "测试中文"

  • 如果输出正常 显示 测试中文 → 问题解决。

  • 如果还是乱码 → 告诉我你的操作系统和终端类型，我再帮你针对性排查。

先试一下 echo $LANG 看看结果，告诉我你用的系统（Windows/Mac/Linux）和终端（CMD/Git Bash/PowerShell），我帮你确认下一步该怎么做。

从你提供的截图信息来看，问题已经很清楚了：文件编码（UTF-8）和换行符（LF）都没问题 ，但脚本并没有执行成功（退出码code=1表示执行出错），而且终端里只输出了一个孤立的字母 I。

这通常是因为运行方式不对 。你很可能通过某种方式直接执行了文件内容 ，而不是文件本身。

🔍 问题根源

从终端输出看，脚本的每一行都被当作命令逐条执行了：

text

复制代码 
shell > hello.sh
shell > #!/bin/bash
shell > echo "Hello, VSCode!"
shell > echo "当前路径: $(pwd)"

#!/bin/bash 被当作普通文本打印了出来，说明Shell解释器没有正常工作 。这通常是运行了 bash < hello.sh 这类"重定向"方式，而不是常规的 bash hello.sh。

✅ 解决方案：用正确的方式运行

试试以下两种最标准的运行方式：

方式一：用 bash 命令运行（推荐）

在终端中输入：

bash

复制代码 
bash d:/CodeForData/shell/hello.sh

方式二：先给执行权限，再直接执行

bash

复制代码 
chmod +x d:/CodeForData/shell/hello.sh
./hello.sh
bash 复制代码 
PS D:\CodeForData> bash d:/CodeForData/shell/hello.sh
/bin/bash: d:/CodeForData/shell/hello.sh: No such file or directory
PS D:\CodeForData> bash shell/hello.sh
Hello, VSCode!
当前路径: /mnt/d/CodeForData
PS D:\CodeForData>

太好了！问题已经找到了，而且你成功跑通了脚本！🎉

🔍 问题根源

bash

复制代码 
bash d:/CodeForData/shell/hello.sh   # ❌ 报错：No such file or directory
bash shell/hello.sh                  # ✅ 成功运行

原因 ：在 Git Bash 环境中，路径写法有讲究：

写法 是否生效 说明
d:/CodeForData/shell/hello.sh ❌ Git Bash 对 盘符: 这种 Windows 风格路径解析有时会出问题
shell/hello.sh ✅ 相对路径 ，从当前所在目录（D:\CodeForData）开始找，最可靠
/mnt/d/CodeForData/shell/hello.sh ✅ Git Bash 把 Windows 盘符映射到 /mnt/ 下，这是绝对路径的正确写法

✅ 最佳实践建议

以后运行脚本，优先用这两种方式之一：

bash

复制代码 
# 方式一：相对路径（从当前位置开始）
bash shell/hello.sh

# 方式二：Git Bash 标准的绝对路径
bash /mnt/d/CodeForData/shell/hello.sh

📌 关于终端输出

你看到 当前路径: /mnt/d/CodeForData，说明：

  • Git Bash 把 D:\CodeForData 映射成了 /mnt/d/CodeForData

  • 这是正常的，在 Git Bash 中 /mnt/d/ 就是 Windows 的 D 盘

之前说运行方式不对，就是点击右上角的 ▶ 运行 小三角，是因为Code Runner没有生效吗

是的，你说得对，就是 Code Runner 这个插件没配置好。问题根源在于它没有在正确的 Shell 环境（Git Bash）里执行你的脚本。

它右上角的"▶ 运行"按钮，核心功能是自动调用你系统的 Shell 来执行脚本 。但你当时是在 Windows 的 PowerShell 环境下，PowerShell 并不原生支持 .sh 脚本，所以脚本的每一行都被当成了命令去执行，导致最终失败。

🔧 让 Code Runner 正常工作的配置步骤

按下面的流程操作，之后就能一键运行了：

  1. 找到 settings.json 文件：

    • 在 VSCode 中按下 Ctrl + Shift + P，输入 Preferences: Open Settings (JSON)，回车打开。

    • 或者直接参考你的截图，侧边栏已经有了 .vscode/settings.json 文件，直接打开它。

  2. 粘贴下面的配置 ：

    把你之前已有的配置信息替换成下面的内容：

    json

    复制代码 
    {
    // 告诉 Code Runner，对于 .sh 文件，用 Git Bash 来执行
    "code-runner.executorMap": {
        "shellscript": "D:\\Tools\\Git\\bin\\bash.exe"
    },
    // 在 VSCode 的内置终端里运行，这样能看到输出
    "code-runner.runInTerminal": true,
    // 强制忽略脚本开头的 #!/bin/bash，直接使用我们指定的 bash.exe
    "code-runner.respectShebang": false
}

    注意 ：请务必将 D:\\Tools\\Git\\bin\\bash.exe 替换成你电脑上 bash.exe 的真实路径。

  3. 保存并重启 VSCode ：保存 settings.json 后，重启一下 VSCode 让配置生效。

电脑上 bash.exe 的真实路径 怎么查询

在 Windows 上查询 bash.exe 的真实路径，有几种简单的方法，我按推荐顺序列出来：

方法一：在命令行中用 where 命令（最快）

打开 CMD 或 PowerShell，执行：

cmd

复制代码 
where bash

如果系统路径里有，会直接返回完整路径，例如：

text

复制代码 
D:\Tools\Git\bin\bash.exe

方法二：在 Git Bash 中用 which 命令

如果你已经打开了 Git Bash，执行：

bash

复制代码 
which bash

会返回类似：

text

复制代码 
/usr/bin/bash

这表示在 Git Bash 的虚拟文件系统里，/usr/bin/ 目录下。它实际对应的 Windows 路径通常是 D:\Tools\Git\usr\bin\bash.exe（注意是 usr\bin 而不是 bin）。

bash 复制代码 
C:\Users\86178>where bash
C:\Users\86178\AppData\Local\Microsoft\WindowsApps\bash.exe

你这个 where bash 的结果，暴露了一个非常典型的 Windows 环境陷阱。

你查到的路径：

text

复制代码 
C:\Users\86178\AppData\Local\Microsoft\WindowsApps\bash.exe

这个路径指向的是 Windows 自带的 WSL (Windows Subsystem for Linux) 入口 ，而不是你安装的 Git Bash。

⚠️ 为什么这个路径不行？

  1. 它是一个"假"入口 ：这个 bash.exe 实际上是个启动器，它会尝试启动 WSL。如果 WSL 没装或没配置好，它可能会执行失败或行为异常。

  2. 它不在 Git 目录下 ：你需要的 Git Bash 的 bash.exe，应该在 Git 的安装目录里（比如 D:\Tools\Git\bin\bash.exe），而不是 WindowsApps 这个系统目录。

简单说：你找到的是 WSL 的 bash，不是 Git Bash 的 bash。

✅ 正确做法：找到 Git 安装目录下的 bash.exe

在同一个 CMD 窗口里，执行：

cmd

复制代码 
where git

这会返回 git.exe 的路径，例如：

text

复制代码 
D:\Tools\Git\bin\git.exe

然后 bash.exe 就在同一目录 （D:\Tools\Git\bin\）下，或者上一级目录的 usr\bin\ 下。

📌 补充：为什么 where git 能找到，但 where bash 找不到 Git Bash 的？

因为 git 命令在安装 Git 时，安装程序会把 git.exe 所在的目录添加到系统的 PATH 环境变量里。但 bash.exe 通常不会 被添加到 PATH 里，所以 where bash 只会找到 WindowsApps 里的那个。

所以你需要通过 where git 来反推 Git 的安装目录，再手动找到 bash.exe。

bash 复制代码 
C:\Users\86178>where git
C:\Program Files\Git\cmd\git.exe

你的 Git 安装在 C:\Program Files\Git\ 下。

🎯 你的 bash.exe 真实路径

根据 where git 的结果（C:\Program Files\Git\cmd\git.exe），bash.exe 应该在：

text

复制代码 
C:\Program Files\Git\bin\bash.exe

✅ 验证一下

在 CMD 或 VSCode 终端里执行：

cmd

复制代码 
"C:\Program Files\Git\bin\bash.exe" --version

如果能正常输出版本号，比如 GNU bash, version 5.2.15，就说明路径正确。

bash 复制代码 
C:\Users\86178>"C:\Program Files\Git\bin\bash.exe" --version
GNU bash, version 5.2.37(1)-release (x86_64-pc-msys)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

C:\Users\86178>

bash.exe 路径验证通过，版本号也正常输出了（5.2.37）。

✅ 现在按以下步骤配置 Code Runner

1. 打开 VSCode 的 settings.json

  • 按 Ctrl + Shift + P

  • 输入 Preferences: Open Settings (JSON)，回车

2. 将以下配置粘贴进去

json

复制代码 
{
    "code-runner.executorMap": {
        "shellscript": "C:\\Program Files\\Git\\bin\\bash.exe"
    },
    "code-runner.runInTerminal": true,
    "code-runner.respectShebang": false
}

如果 settings.json 里已经有其他配置，不要覆盖 ，只需把 code-runner 相关的几个配置项加进去或合并进去即可。如果某个键已经存在，就更新它的值。

因为你的 settings.json 本来就是空的（或者只有之前我让你配的那几条），所以直接把下面这段完整复制进去，保存即可。

3. 保存文件（Ctrl + S）

4. 重启 VSCode（让配置生效）

bash 复制代码 
PS D:\CodeForData> C:\Program Files\Git\bin\bash.exe "d:\CodeForData\shell\hello.sh"
C:\Program : 无法将"C:\Program"项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼
写，如果包括路径，请确保路径正确，然后再试一次。
所在位置 行:1 字符: 1
+ C:\Program Files\Git\bin\bash.exe "d:\CodeForData\shell\hello.sh"
+ ~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Program:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
 
PS D:\CodeForData>

问题出在PowerShell 对路径中空格的处理方式上。

你直接输入 C:\Program Files\...，PowerShell 会把 C:\Program 当成命令，把 Files\Git\bin\bash.exe 当成参数，所以就报错了。

🔍 问题根源

Code Runner 运行脚本时，实际上是在后台调用了类似这样的命令：

powershell

复制代码 
C:\Program Files\Git\bin\bash.exe "d:\CodeForData\shell\hello.sh"

由于路径 C:\Program Files 中包含空格 ，PowerShell 无法正确解析，所以报错 无法将"C:\Program"项识别为 cmdlet...。

✅ 解决方案

在 settings.json 中，把路径改成短路径名（不包含空格）的形式：

json

bash 复制代码 
{
    "code-runner.executorMap": {
        "shellscript": "C:\\PROGRA~1\\Git\\bin\\bash.exe"
    },
    "code-runner.runInTerminal": true,
    "code-runner.respectShebang": false
}

C:\PROGRA~1 是 C:\Program Files 的短名称（8.3格式），不包含空格，PowerShell 能正常识别。

📌 为什么之前 where git 返回的是 C:\Program Files\Git\cmd\git.exe，但短路径能用？

Windows 为每个包含空格的路径自动生成了一个短名称（8.3格式），C:\PROGRA~1 就是 C:\Program Files 的短名称。这个短名称在命令行中完全合法，PowerShell 不会把它拆成两段。

改了路径"shellscript": "C:\\PROGRA~1\\Git\\bin\\bash.exe"后测试运行正常

🎉 完美！问题解决了！

✅ 总结一下这次踩坑的全过程

步骤 问题 解决方案
1 点 ▶ 运行，脚本没执行，只输出零散内容 Code Runner 默认调用了 PowerShell，不是 Git Bash
2 where bash 找到了 WSL 的 bash 入口，不是 Git Bash 的 用 where git 反推 Git 安装目录，找到真正的 bash.exe
3 "C:\Program Files\Git\bin\bash.exe" 路径有空格 改用短路径 C:\PROGRA~1\Git\bin\bash.exe

📌 以后写 Shell 脚本的工作流

  1. 新建 .sh 文件（VSCode 自动识别语法）

  2. 写脚本内容 （Shebang 行 #!/bin/bash + 命令）

  3. 点右上角 ▶ 运行 （Code Runner 调用 Git Bash 执行）

  4. 看终端输出（成功！）

💡 顺便说一下

你现在已经会用 VSCode 写 Shell 脚本了，这套流程完全可以覆盖日常 ETL 调度脚本、数据处理脚本、运维脚本 的开发和调试需求。比起用 vim 在黑框里敲代码，效率提升了不止一个档次。

准确来说：vi 是 vim 的前身，而 vim 是 vi 的增强版。

📜 关系演变

阶段 工具 说明
1976年 vi 由 Bill Joy 开发，是 Unix 系统的标准文本编辑器，功能基础。
1991年 Vim 由 Bram Moolenaar 开发，全称 Vi IMproved （改进版 vi），在 vi 基础上增加了语法高亮、插件支持、多级撤销、鼠标操作等大量功能。
现在 vi → vim 在大多数 Linux 发行版中，输入 vi 命令实际指向的是 vim（通过软链接或别名）。

🔍 如何判断你的系统里 vi 指向什么？

执行：

bash

复制代码 
ls -l /usr/bin/vi

如果输出类似：

text

复制代码 
lrwxrwxrwx 1 root root 20 ... /usr/bin/vi -> /etc/alternatives/vi

再执行：

bash

复制代码 
ls -l /etc/alternatives/vi

如果指向 vim，说明输入 vi 实际打开的是 Vim。

📌 一句话总结

  • vi = 老牌编辑器（原始版）

  • vim = vi 的增强版（现在大部分系统输入 vi 实际调用的就是 vim）

  • 日常使用 ：你敲 vi 和 vim，在绝大多数现代系统上效果一样，差别极小。

所以，vi 是 vim 的前身，vim 是 vi 的增强版。在今天的语境下，说 "用 vi 编辑" 和 "用 vim 编辑" 基本等价。

Shell 不仅有多个版本，而且不同"家族"之间的语法确实不兼容。

核心的两大家族：Bourne 与 C

市面上形形色色的 Shell，基本都能追溯到两大源头：Bourne Shell 和 C Shell。它们的语法风格完全不同，就像说两种不同的语言。

家族 核心代表 语法风格 主要特点
Bourne 家族 sh, bash , ksh, zsh 语法源自早期的 Bourne Shell 是Linux/Unix的主流，语法被POSIX标准采纳。我们日常说的Shell脚本，绝大多数指的就是Bourne家族的脚本。
C 家族 csh, tcsh 语法酷似 C 语言 在BSD Unix系统中流行，但和Bourne家族的脚本不兼容，交互方式不同。

"不兼容"的典型例子

这种不兼容，最直接的体现就是变量赋值：

  • Bourne家族 (bash/sh) : 直接用 variable=value

  • C家族 (csh) : 需要用 set variable = value

所以，你为一个Shell写的脚本，放到另一个家族里大概率跑不起来。

最常见的情况：sh 与 bash

在日常工作中，最常见的"兼容性"问题，其实是 sh 和 bash 的区别。sh (Bourne Shell) 是早期的版本，功能比较基础；而 bash (Bourne-Again SHell) 是其增强版，是目前大多数Linux系统的默认Shell。

一个关键点是：在很多系统上，/bin/sh 这个程序只是一个指向 /bin/bash 的软链接 。不过，当 bash 以 sh 的名字被调用时，它会启用 POSIX 兼容模式，主动关闭自己的一些扩展功能。

因此，如果你的脚本开头是 #!/bin/sh，它就必须遵守更严格的POSIX标准；如果是 #!/bin/bash，就可以使用更多方便的高级特性。所以，一个在Linux上运行正常的 bash 脚本，在另一个用 dash（一个更轻量的Shell）作为 /bin/sh 的系统（如Ubuntu）上执行时，就可能因语法不兼容而报错。

Bash 和 Dash 的核心区别

Bash 是功能丰富的交互式 Shell，而 Dash 是追求极致性能的轻量级脚本执行 Shell，它们的设计目标完全不同。

对比维度 Bash (Bourne Again SHell) Dash (Debian Almquist Shell)
核心定位 功能强大的交互式 Shell和脚本语言 POSIX 兼容的轻量级 Shell，专为脚本执行优化
设计目标 丰富的交互功能，兼容 Bourne Shell 并扩展 极致的执行速度和低内存占用
性能差异 功能多，启动和脚本执行相对慢 脚本执行速度大约是 Bash 的 4 倍
语法特性 支持数组、[[ ]]高级条件判断、进程替换等大量扩展特性 严格遵循 POSIX 标准，不支持 Bash 独有扩展语法
典型用途 登录 Shell、日常命令行操作、编写复杂脚本 作为 /bin/sh 执行系统初始化脚本、软件包管理脚本

简单来说，你用 Bash 时能用很多"高级语法"，而 Dash 只认最基础的 POSIX 标准。如果脚本里用了 [[ ]] 或数组，用 Dash 执行就会报错。

🖥️ 关于你的两个疑问

1. WSL2 中是 Dash 吗？

不完全准确，需要区分场景。

  • 作为 /bin/sh ：在 Ubuntu/Debian 等发行版中，/bin/sh 默认是指向 Dash 的。所以，当系统执行那些声明为 #!/bin/sh 的脚本时，用的就是 Dash。

  • 作为交互式 Shell ：当 WSL 为你的用户账户启动时，默认的交互式登录 Shell 是 Bash。

所以，在WSL2里，你"敲命令"用的是 Bash，但系统后台很多脚本（以 #!/bin/sh 开头）是由 Dash 来执行的。

2. VSCode 里用的是 Bash 吗？

不一定，这完全取决于你的设置。

VSCode 的终端只是一个界面，它具体使用哪个 Shell（Bash、PowerShell、Zsh等），取决于你的系统配置和VSCode设置。

  • 默认行为 ：在WSL的Ubuntu环境中，VSCode通常会继承并使用系统默认的交互式 Shell，也就是 Bash。

  • 可以更改 ：你可以随时通过命令面板（Ctrl+Shift+P -> Terminal: Select Default Profile）将VSCode的默认终端切换成你想要的任何 Shell。

总结一下：你在 VSCode 终端里"用"的（敲命令的那个）很可能就是 Bash；

但 WSL 系统在执行后台脚本时，会优先用 Dash 来追求速度。

热门推荐
012026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？022026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？032026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf04【AI】2026 年具身智能模型和世界模型总结05GitHub 镜像站点06AI科技热点日报 | 2026年6月1日07AI一周事件 · 2026-06-03 至 2026-06-0908Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析09上线仅72小时被强制下架：Claude Fable 5 的短命102026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？