Eclipse 2021-03 C/C++版带&命名C文件引发构建失败的原因及修正

问题核心成因 #

这个报错本质是Shell特殊元字符的解析逻辑与Eclipse生成构建命令的转义缺陷共同导致的：

• &是类Unix Shell（包含Eclipse跨平台构建时调用的/bin/sh、bash环境）的核心特殊控制符，作用是分割前后命令、将前序命令放到后台执行，未被转义或引号包裹时会直接截断原本连续的路径参数。
• 从你提供的构建日志可以看到，编译阶段的命令行对源文件、输出.o目标文件的路径都加了双引号包裹，因此带&的路径没有被Shell拆分，编译环节可以顺利完成。但到链接生成可执行文件的环节，Eclipse 2021-03版本的CDT插件存在转义逻辑缺陷：输入的./src/int&float.o路径没有加双引号包裹，直接被Shell拆分为两段独立内容执行：
  1. 前半段./src/int被拼接到gcc的命令行中，gcc实际收到的输入文件路径只有被截断的./src/int，因此报出gcc: error: ./src/int: No such file or directory
  2. 后半段float.o被识别为独立的待执行系统命令，因为当前环境中不存在同名可执行程序，因此报出/bin/sh: 1: float.o: not found
• 这种转义缺陷是2021-03版本CDT的已知问题，对路径中包含的&等Shell特殊字符，在部分构建环节无法正确完成引号包裹或转义处理。

可落地的修正方案 #

• 通用最优方案：源代码、可执行目标的文件名中避免使用&、|、;、$、反引号、重定向符等Shell特殊元字符，将原文件名Sum of Int&float修改为Sum of Int and float、Sum_of_Int_and_float这类无特殊字符的命名，从根源上消除Shell解析歧义。这也是跨平台C/C++项目开发的通用命名规范，能避免Windows、Linux、Mac不同环境下的构建兼容问题。
• 临时适配方案：如果必须保留带特殊符号的文件名，可以手动修改Eclipse生成的项目makefile，给所有包含&的路径参数加上双引号，同时将路径中的&转义为\&。但这种方案维护成本极高：每次调整项目配置、新增源文件时，Eclipse都会重新生成makefile，覆盖手动修改的内容。
• 版本升级方案：这个路径转义缺陷在Eclipse CDT 2021-09及后续版本中已被修复，有长期使用带特殊符号文件名需求的用户，可以升级CDT到修复后的版本，自动完成特殊字符的转义处理。

内容的提问来源于stack exchange，提问作者Nidheesh