嘿，我太懂你不想碰eval的心态了——这玩意儿要是处理不好，要么出奇怪的bug，要么还可能埋下安全隐患。咱们直接说最靠谱的替代方案：用Bash数组来存储命令和参数，这是避开eval的最优解。

先给你掰扯清楚为啥原来的写法会踩坑：当你把command="echo \"foo bar\""赋值后，Bash在展开$command时，是按空白字符把整个字符串拆成“词”的，这里它会硬生生拆成echo、"foo、bar"三个部分——引号直接变成了参数的一部分，所以输出才会带着引号，完全不是你想要的结果。

换成数组写法就顺畅多了，看例子：

# 把命令和每个独立参数分别放进数组
cmd=(echo "foo bar")
# 严格展开数组执行命令，注意引号和@的组合
"${cmd[@]}"

执行这个你就能得到干净的foo bar输出，完全不需要eval。这里的核心是"${cmd[@]}"的展开逻辑：它会完整保留数组里每个元素的独立性，哪怕元素里有空格、引号或者其他特殊字符，都不会被错误拆分。

结合你做编译器基准测试的场景，数组简直是量身定做。比如你要动态拼接编译器选项、带空格的源文件或输出文件名：

# 构建带复杂参数的编译器命令数组
benchmark_cmd=(gcc -O2 "src/test case with spaces.c" -o "results/benchmark result.out")
# 执行命令
"${benchmark_cmd[@]}"

这样不管参数里有什么特殊情况，都能准确传递给编译器，再也不会因为引号缺失导致报错，而且比eval安全太多——毕竟eval会把变量内容当成代码执行，要是不小心混入恶意内容后果不堪设想，数组就没这个问题。

说白了，用数组替代字符串存储命令和参数，是Bash里处理带空格/特殊字符参数的标准操作，既解决了你的实际问题，又避开了eval的各种坑。

备注：内容来源于stack exchange，提问作者Byron Hawkins