我之前也碰到过这种长命令被截断的情况，确实挺闹心的。下面几个方法应该能帮你拿到完整的命令行：

方法1：用GDB的info proc cmdline命令 #

这是最直接的解决方案，GDB的这个命令会直接读取core文件里进程的原始命令行参数数组，完全不受PRPSINFO字段的长度限制。操作步骤很简单：

1. 启动GDB加载core文件：

   gdb -c core.56536
   

2. 在GDB提示符下执行：

   info proc cmdline
   

输出会清晰展示完整的可执行文件路径和所有参数，比如：

Command line:
myCommand -f log/SlaRunTimeReport.rep -I input/myFile.txt -t output/myFile.txt

方法2：直接打印GDB中的argv变量 #

如果info proc cmdline因为GDB版本过旧等原因不好用，可以直接访问进程的argv数组：
在GDB里执行：

print ((char **)$_argv)

然后逐个打印每个参数元素，比如：

x/s ((char **)$_argv)[0]
x/s ((char **)$_argv)[1]
x/s ((char **)$_argv)[2]
...

这样就能逐个获取完整的参数，不会出现截断问题。

方法3：用Elfutils工具集解析Core文件 #

如果你不想启动GDB，可以用eu-readelf（来自elfutils工具包，大部分Linux发行版可通过包管理器安装）来解析core的栈区域：

1. 先安装elfutils（比如RHEL/CentOS系统：yum install elfutils）
2. 执行命令提取完整命令行：

   eu-readelf --notes core.56536 | grep -A 15 "CORE"
   

或者结合strings全面搜索参数片段：

strings -a core.56536 | grep -E "(-f|-I|-t)"

这样能找到分散在栈里的所有参数，拼起来就是完整命令。

为什么之前的方法会截断？ #

你之前看到的截断内容，来自core文件里的PRPSINFO note段——这个字段被设计成固定长度（通常是160字节），长命令会被自动截断。而info proc cmdline或直接访问argv是读取进程栈里的原始参数数组，那里存储的是完整的独立参数，没有长度限制。

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