[code-review] desktop_control Linux: open/launch_app 拼接含空格命令串作为唯一可执行名传给 exec — open 动作 100% 失败 + 子进程僵尸泄漏

[topcheer]

文件与行号

internal/tool/desktop_control_linux.go:92-102（open/launch_app 分支）、:144-153（runAppResult）

问题描述

runAppResult(ctx, "xdg-open "+target) 把含空格的整个字符串作为 exec.CommandContext(ctx, app) 的唯一可执行文件名传入——exec 不经 shell、不做分词，会在 PATH 中查找名为 xdg-open https://example.com 的可执行文件，必然不存在。

触发场景

Linux 上任何 desktop_control {action:"open", text:"https://example.com"} 调用：

• 默认分支："xdg-open "+target 一定含空格 → 100% 失败（exec: no such file or directory）
• 带 app 参数分支：app+" "+target 同样拼接 → 同样失败
• launch_app：p.Text 含参数（如 "firefox --private-window"）时失败

对照 macOS 版（desktop_control_darwin.go 的 openTarget）正确使用 exec.CommandContext(ctx, "open", args...) 程序名与参数分离——Linux 版是参数拼接方式写错，非有意设计。

附带：cmd.Start() 后从不 cmd.Wait()，子进程退出后成僵尸进程，长驻进程反复 launch_app 会累积。

预期行为 vs 实际行为

• 预期：Linux 上 open 动作用 xdg-open 打开 URL/文件
• 实际：exec 查找名为整串拼接文本的可执行文件，必然报错

修复建议

runAppResult 改为接收 name string, args ...string；open 默认分支传 ("xdg-open", target)；App 分支拆分 app 与 target；Start 成功后 go func() { _ = cmd.Wait() }() 收割子进程。

严重程度

High（经独立 subagent 复核确认：Linux 上 open 动作 100% 功能性失效，无 workaround）

[topcheer]

已修复，commit 5b7b6712（internal/tool/desktop_control_linux.go）：runAppResult 改为 (name, args...) argv 形式，xdg-open/app/launch_app 均正确分离程序名与参数；Start 后后台 Wait 收割子进程，消除僵尸泄漏。X11 与 Wayland 共享路径同步修复。