Arduino CH552编译报错sdcc.sh syntax error？Shell解释器bash与dash差异排查

本来这次编译应该是三分钟以内的事：Arduino IDE 里选好 CH552 开发板，写一个经典的 Blink，然后点上传。结果编译进度条走到一半，输出区弹出一行孤零零的提示：

sdcc.sh: syntax error: unexpected "("

没有指向某个 .ino 文件的行号，没有几百行编译器告警。我第一次看到这个报错的时候，第一反应是翻自己代码里有没有少括号。后来才搞明白，这其实跟代码一点关系都没有，问题出在 Arduino 工具链的 Shell 包装层。这篇文章就完整记录我那次排查和修复的过程。如果你也在用 CH55xDuino 或者其他依赖 sdcc.sh 这类脚本的 Arduino 第三方核心，下面这些步骤应该能帮你省掉不少弯路。

1. 先稳住：这个报错真的跟你的 Arduino 代码无关

很多人遇到syntax error的第一反应是去看自己写的.ino文件，尤其是当 IDE 又把当前文件名显示在顶部的时候，很容易形成“是不是我哪里括号没配对”的错觉。但这次不一样，关键在于错误信息里的主语：sdcc.sh。

先理清 Arduino 的编译流水线。看起来很简单的“点一下上传”，背后其实是好几步串联：预处理.ino文件、调用编译器把 C/C++ 源码编成目标文件、链接、生成 hex、最后才是通过 bootloader 或 USB 写入芯片。对于 CH552 这种 E8051 内核的芯片，编译器并不是 AVR GCC，而是 SDCC。CH55xDuino 这个第三方硬件支持包，把 SDCC 的调用封装了一层，这层封装通常就是一个 Shell 脚本，名字就叫sdcc.sh。

所以当你看到sdcc.sh: syntax error: unexpected "("，它的意思是：这个脚本在 Shell 解析阶段就已经挂了，真正的编译器 SDCC 压根没被跑起来。就像你准备打电话给快递员，结果发现电话机自己的拨号电路坏了，问题在话机本身，不在你要说的内容。

怎么确认这一点？最简单的方法是把 Arduino IDE 的详细输出打开。在 Linux 或 macOS 下，路径通常是File → Preferences → Show verbose output during compilation，勾上之后重新编译，你就能在输出面板里看到被拼接出来的完整命令行。在我当时的环境里，它长这样：

/home/user/Arduino/hardware/ch55xduino/tools/sdcc/sdcc.sh -mcs51 --std-c99 -DF_CPU=16000000L -DCH552 -Isrc

看到这一整条命令后，先把你的.ino代码放一边，把命令行完整复制下来，下一步直接在终端里手动跑一遍。这一步非常关键，它能帮你把“Arduino IDE 整合环境”这个变量隔离掉，直接验证问题是不是出在工具链本身。

2. 揪出 sdcc.sh：Arduino 编译流水线里的“编译器代理”

sdcc.sh这名字起得很容易让人误解，你可能会以为它就是 SDCC 编译器。其实它是一个包装脚本。相当于编译器团队的“前台接待”：真正的 SDCC 二进制文件可能存放在sdcc/bin/sdcc这样的子目录里，脚本负责修正路径、设置 PATH、处理参数，最后再把真正的编译命令转发给 SDCC。

为什么要多此一举？因为 Arduino 的 recipe 模板是通用的，第三方核心要适配不同的操作系统和目录结构，直接写死绝对路径显然不现实。脚本可以把“当前脚本所在目录”“编译器的实际安装目录”“参数前缀”这些运行时信息在启动时动态算出来，再拼成一条完整的 SDCC 调用。这样 Arduino IDE 的platform.txt不用塞进大量本地路径信息，维护起来干净很多。

我在自己的目录里打开这个脚本看了一部分，简化后大概是这种感觉：

#!/usr/bin/env bash TOOL_DIR="$(cd "$(dirname "$0")" && pwd)" export PATH="$TOOL_DIR/bin:$PATH" ARGS=() while [ $# -gt 0 ]; do case "$1" in -L*) ARGS+=("$TOOL_DIR$1") ;; *) ARGS+=("$1") ;; esac shift done exec "$TOOL_DIR/bin/sdcc" "${ARGS[@]}"

这种写法在 bash 下没有任何问题。ARGS=()是声明一个空数组，ARGS+=("...")是往数组里追加元素，最后"${ARGS[@]}"是展开成完整的参数列表，而且能正确处理带空格的参数。但注意看第一行：

#!/usr/bin/env bash

这份脚本明确要 bash。如果系统里有一个地方绕过了这个 shebang，用别的 Shell 去加载它，问题就来了。

怎么查看自己的脚本长什么样、调用方式是什么？两件事：第一，直接在终端执行：

cat -n sdcc.sh | head -20

第二，看 Arduino 的platform.txt里是怎么引用它的。CH55xDuino 的安装目录一般在~/Arduino/hardware/ch55xduino/，platform.txt就在里面，搜sdcc.sh关键词，你会看到类似这样的一行：

recipe.c.o.pattern=sh {compiler.path}/sdcc.sh -mcs51 ...

注意这里，如果 recipe 里写的是sh sdcc.sh，那即使脚本第一行写了#!/usr/bin/env bash，也没用，因为sh会把它当前的 Shell 当作解释器去执行脚本内容。这就为后续的语法错误埋下了雷。

3. unexpected "(" 到底哪里不对：dash 与 bash 的语法分歧

先回答一个基础问题：为什么系统里明明有 bash，还会用 sh 去执行脚本？

在很多 Linux 发行版上，/bin/sh并不指向 bash。Ubuntu、Debian 以及它们的衍生版，/bin/sh默认是指向 dash 的。dash 是一个更精简、更快的 POSIX 兼容 Shell，脚本执行效率比 bash 高，但它只支持 POSIX 语法，不支持 bash 的许多扩展特性。

可以快速验证你系统的/bin/sh指向哪里：

ls -l /bin/sh

在我当时的环境里，输出是：

/bin/sh -> dash

这一下就对上了。脚本里的ARGS=()这种空数组赋值不是 POSIX 语法，dash 解析到这一行时，看到等号后面出现左括号，直接判定“这什么东西”，于是给出syntax error: unexpected "("。

我把 bash 和 dash 对几种常见语法的兼容性整理成了下面的表格，遇到类似问题可以快速对照：

还有个细节值得注意：$(...)这种命令替换在 POSIX 里是合法的，bash 和 dash 都支持，所以如果脚本里有"$(cd "$(dirname "$0")" && pwd)"，这行不会触发问题。真正引爆的往往就是数组相关语法，或者[[ ]]双中括号。

怎么验证确实是这个问题？很简单，用两个不同的 Shell 分别对脚本做语法检查：

bash -n sdcc.sh && echo "bash: OK" dash -n sdcc.sh

bash -n表示只做语法解析不执行，如果脚本在 bash 下语法通过，它会打印 OK。而dash -n sdcc.sh则会直接在报错处停下来。我当时跑完，输出基本是：

bash: OK sdcc.sh: 9: Syntax error: "(" unexpected

行号可能和你那边不完全一样，但结论很清晰：同一个脚本，bash 觉得没问题，dash 觉得有语法错误。那问题不在脚本内容本身，而在“用哪个 Shell 去解释它”。

4. 完整排查链路：从一次性复现到永久修复

接下来是实际操作过程。我按时间顺序记录一下整个排查和修复过程，你可以照着复用。

4.1 拿到完整命令并手动复现

首先，开启 Arduino IDE 的 verbose 编译输出，重新编译一次。把输出面板里那条以sdcc.sh开头的命令整行复制出来，在终端里手动执行。这一步是为了确认：报错是否稳定复现？

我的经验是，手动执行时尽量把工作目录切到 Arduino 当前工程目录下，因为某些 recipe 会依赖相对路径。命令执行后，果然复现了同样的错误：

$ /home/user/Arduino/hardware/ch55xduino/tools/sdcc/sdcc.sh -mcs51 --std-c99 -DF_CPU=16000000L ... sdcc.sh: 9: Syntax error: "(" unexpected

然后我把脚本路径换成bash显式调用：

$ bash /home/user/Arduino/hardware/ch55xduino/tools/sdcc/sdcc.sh -mcs51 --std-c99 -DF_CPU=16000000L ...

编译正常往下走了。这一步基本上就锁定了问题方向：脚本本身没坏，是解释器不对。

4.2 检查 shebang 和 platform.txt 调用方式

接着检查脚本第一行，确认它写的是#!/usr/bin/env bash。既然 shebang 没问题，那为什么 Arduino IDE 调用时会用错解释器？答案就是我在第 2 节提到的：platform.txt里的 recipe 用sh显式调用了脚本。打开文件搜索后，我看到的调用模式是：

recipe.c.o.pattern=sh {compiler.path}/sdcc.sh ...

syntax error就是这么来的。sh先启动 dash，dash 把脚本读进来解析，撞上数组语法直接翻车。

4.3 选择修复方案

摆在面前的有三条路，我按推荐程度排一下：

方案一：修改 platform.txt，把sh改成bash

这是最省事、最直接的方案。把sh {compiler.path}/sdcc.sh改成bash {compiler.path}/sdcc.sh。如果你的 recipe 里没有写sh，而是直接写的脚本路径，那说明脚本在系统里是通过 shebang 被直接执行的，理论上不会出这个问题；但如果你的系统/bin/sh是 dash，Arduino CLI 或某些构建环境可能会用sh -c把整条 recipe 包一层，这时同样可以尝试把脚本路径前显式加bash。

方案二：修改 sdcc.sh 的 shebang

把第一行改成#!/bin/bash。这个方案对直接执行脚本的场景有效，但如果 recipe 里用sh sdcc.sh显式调用，shebang 会被忽略，解决不了问题。所以要么先看调用方式，再决定改哪里。

方案三：把脚本语法改成 POSIX 兼容

这是最根源的解法。既然脚本需要被各种环境调用，与其假设每个系统都有 bash，不如把 bash 特有的语法去掉。比如把数组改成set --累计参数的方式：

#!/bin/sh TOOL_DIR="$(cd "$(dirname "$0")" && pwd)" export PATH="$TOOL_DIR/bin:$PATH" set -- while [ $# -gt 0 ]; do case "$1" in -L*) set -- "$@" "$TOOL_DIR$1" ;; *) set -- "$@" "$1" ;; esac shift done exec "$TOOL_DIR/bin/sdcc" "$@"

这个版本完全用 POSIX 语法，dash 和 bash 都能跑。我本地的验证结果是：脚本在两种 Shell 下都能正常完成参数拼接并启动真正的 SDCC 编译。

我当时先用了方案一，毕竟改动最小，编译和烧录立刻恢复正常。后来为了以后少踩坑，我又顺手把脚本本身改成 POSIX 兼容版，这样哪怕之后 recipe 被别人改回sh，也不会再炸。

4.4 验证修复结果

修复之后，回到 Arduino IDE，先执行一次“清理编译缓存”，再重新编译上传。这一步很重要，因为 Arduino IDE 有时候会缓存旧的对象文件，如果你只改环境不清缓存，可能看起来还是同样的报错。菜单路径一般是Sketch → Clean或者手动删除build目录下的临时文件。

正常情况下，你会看到编译日志继续往下走，出现类似这样的输出：

Sketch uses 13240 bytes (24%) of program storage space. Global variables use 3 bytes (0%) of dynamic memory.

然后烧录成功，板子上的 LED 按预期闪烁起来。走到这一步，问题彻底解决。

5. 修复之外：三个容易忽略的环境级隐藏坑

CH55xDuino 编译报错这件事，我后续又在不同的机器上遇到过几次，也帮朋友排查过类似问题。除了“dash 不认 bash 语法”这个主因之外，还有几个环境级隐患容易被忽略，尤其是当你从别人那里拷脚本、从 Windows 编辑器改过文件、或者项目路径有点“特殊”的时候。

5.1 脚本文件被存成 CRLF 换行

Shell 脚本必须用 LF（Unix 换行）结尾，如果脚本在 Windows 上被某些编辑器保存为 CRLF，那每一行末尾都会多一个\r字符。这个\r在解析时会被当成参数的一部分，轻则出现奇怪的命令找不到，重则直接语法错乱。

检查方法非常快：

file sdcc.sh

如果输出里有with CRLF line terminators，恭喜你，中招了。修复：

dos2unix sdcc.sh

或者不用额外装工具：

sed -i 's/\r$//' sdcc.sh

5.2 文件开头多了 BOM

UTF-8 BOM 是写在文件最前面的三个字节EF BB BF。问题在于，BOM 出现在脚本第一行的时候，shebang 就变成了\xef\xbb\xbf#!/bin/bash，内核和 Shell 都认不出这个 shebang，脚本内容会以某种诡异的方式被解释，报错千奇百怪。

用十六进制看一眼开头就能确认：

head -c 16 sdcc.sh | od -An -tx1

如果开头出现ef bb bf，直接去掉：

sed -i '1s/^\xEF\xBB\xBF//' sdcc.sh

5.3 工程目录或用户名包含括号等特殊字符

这一类问题在 Windows 加 MSYS2/Git Bash 的组合下特别容易出现。如果你的用户名是Jhon (Dev)这种带括号的，路径拼接进命令行后，bash 或 dash 可能会把路径里的括号当成语法结构的一部分来解析，同样会报unexpected "("。

验证方法很简单：把工程临时复制到一个纯英文、无空格、无括号的路径下，重新编译。如果编译过了，说明就是路径字符问题。日常开发我建议在工具链安装目录和 Arduino 工程目录里都避免使用带括号的目录名。这个建议听起来很基础，但很多人栽在这上面。

把这三个隐患连同上面的主因汇总起来，排查时可以直接先扫一遍环境：

6. 复盘笔记：以后再碰到工具链脚本报错的思路

折腾完这一趟之后，我给自己总结了一个排查工具链问题的三层定位法，之后遇到类似的情况都是按这个思路走的：

第一层，先看应用层。如果你的.ino代码有语法错误，编译器会明确告诉你哪个文件哪一行。但像sdcc.sh: syntax error这种错误，主语不是编译器本体，说明问题在应用层之外。

第二层，再查工具层。工具层指的是包装编译器的那一层脚本。遇到脚本报语法错误，别急着改脚本内容，先确认这个脚本是被谁、用什么解释器调起来的。bash -n和dash -n交叉验证，能在一分钟内判断出到底是脚本坏了还是解释器不对。

第三层，最后看环境层。Shell 指向、编码格式、路径字符，这些环境因素成了“薛定谔的报错”——换个终端正常，换个用户目录就炸。把这些环境变量一项项核过去，往往能挖出隐藏很深的根因。

我现在还有个习惯：每次给板子换工具链或者重装 Arduino 核心，都会在第一时间拿最小工程跑一次编译，把 verbose 日志完整存到一个文本文件里。后面万一出问题，翻出这份日志对照当前命令行，很多问题的定位时间能从半小时压缩到五分钟。

CH55xDuino 是个挺有意思的项目，CH552 这颗几块钱的芯片能用 Arduino 生态来开发，性价比很高。不过它的工具链毕竟是从 SDCC 和 Shell 脚本这种比较“朴素”的环节搭起来的，不像 AVR 核心那样被官方打磨得那么圆滑。遇到工具链层面的报错，心态放平，按“环境 → 调用方式 → 脚本内容”的顺序排查，大部分坑其实都是可以绕过去的。