通过Bash变量传递-ex断点参数给gdb命令行失败的原因是什么

根因分析 #

这个问题是Bash的变量展开规则导致的，和gdb本身无关：

• 直接在命令行执行第一种写法时，Bash会先解析命令里的单引号，把'break file.cpp:100'识别为一个完整的参数，最终传给gdb的参数列表为：

  [0] gdb
  [1] -ex
  [2] break file.cpp:100
  [3] -ex
  [4] run
  [5] --args
  [6] myProg
  

  完全符合gdb的参数要求，所以能正常设置断点。
• 第二种写法把参数存到变量后直接调用时，Bash只会按照空白字符拆分变量内容，不会再解析变量内部的单引号，变量$BP1会被拆成3个独立的参数：

  [1] -ex
  [2] 'break
  [3] file.cpp:100'
  

  相当于你给gdb传了带多余单引号的碎参数，gdb无法识别为合法的断点指令，自然会失效。

修复方案 #

方案1：用Bash数组存储参数（最推荐） #

把每一个独立参数作为数组的单独元素，展开时就能保留参数边界：

# 定义参数数组，每个参数单独占一个元素位
BP_OPTS=(-ex 'break file.cpp:100')
# 用 "${数组名[@]}" 展开，完全保留参数格式
gdb "${BP_OPTS[@]}" -ex run --args myProg

这种方案兼容性好、无安全风险，是shell里存储多参数的标准写法。

方案2：用eval强制重解析（仅作了解，不推荐） #

如果一定要用普通变量存储，可以加eval让Bash重新解析整行命令的引号规则：

BP1="-ex 'break file.cpp:100'"
eval gdb $BP1 -ex run --args myProg

注意这种方案存在代码注入风险，如果变量内容包含不可信输入，可能导致任意命令执行，日常使用优先选数组方案。

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