Bug: persistent-bash 的 eval -- 是 bashism，非 bash 持久 shell 下每条命令 exit 127 | eval -- breaks every non-bash persistent shell

[sjh9714]

摘要 / Summary

@deepseek-ai/dsh-tool-bash-persistent 的 wrapCommand() 用 eval -- 包裹每一条命令。-- 是 bash 的写法，busybox ash 的 eval 内建不认它，会把 -- 当成命令名。结果是：只要持久 shell 不是 bash，每一条命令都在真正执行前就死于 not found / exit 127。

wrapCommand() in @deepseek-ai/dsh-tool-bash-persistent wraps every command in eval --. The -- end-of-options separator is a bashism; busybox ash's eval builtin does not implement it and takes -- as the command name. So whenever the persistent shell is not bash, every command dies with not found / exit 127 before it ever runs.

位置 / Where

@deepseek-ai/dsh-tool-bash-persistent/lib/index.js:91 (v0.1.0-rc.6)

function quoteForBash(value) {
	return `$'${value.replaceAll("\\", "\\\\").replaceAll("'", "\'").replaceAll("\r", "\r").replaceAll("\n", "\n")}'`
}

function wrapCommand(command, marker) {
	return `printf '%s\n' ${quoteForBash(marker.start)}; eval -- ${quoteForBash(command)}; __dsh_persistent_bash_status=$?; printf '%s%s\n' ${quoteForBash(marker.end)} "$__dsh_persistent_bash_status"`
}

$'...' ANSI-C 引用本身没问题，busybox ash 支持。唯一的不兼容就是 -- 这一个 token。
The $'...' quoting is fine — busybox ash supports it. The -- token is the only incompatibility.

最小复现 / Minimal repro

不需要 DSH，一行就能看到 / No DSH needed:

$ busybox sh -c 'eval -- echo hi'
sh: eval: line 0: --: not found      # exit 127
$ busybox sh -c 'eval echo hi'
hi                                   # exit 0
$ bash -c 'eval -- echo hi'
hi                                   # exit 0

把 wrapCommand() 的真实产物原样跑一遍 / The actual wrapCommand() output, run verbatim:

printf '%s\n' $'START'; eval -- $'echo hi'; st=$?; printf 'END:%s\n' "$st"
#   busybox ash -> START / sh: eval: line 1: --: not found / END:127
#   bash        -> START / hi / END:0

环境 / Environment: BusyBox v1.38.0-FRP-6075-g169694ebd (2026-05-06, busybox-w32), Windows 11 26100, node 24.19.0, @deepseek-ai/dsh 0.1.0-rc.6.

修复建议 / Suggested fix

请不要只是删掉 -- —— 那样 bash 会回归。实测四种写法 / Do not simply drop --, that regresses bash. All four forms measured:

写法 / form	bash	busybox ash
eval -- $'-n hi' （现状 / today）	-n: command not found (127) ✅	--: not found (127) ❌
eval $'-n hi' （直接删 / naive drop）	eval: -n: invalid option (2) ❌	-n: not found (127) ✅
eval $' -n hi' （前导空格 / leading space）	-n: command not found (127) ✅	-n: not found (127) ✅
eval $' echo ok'	ok (0) ✅	ok (0) ✅

-- 的作用是防止以 - 开头的命令被 eval 当成选项。在被引用的字符串前加一个空格能达到同样效果，而且是可移植的：参数本身以空格开头，就不会进入选项解析；前导空白对 shell 解析没有影响。

-- exists to stop a command starting with - from being parsed as an option to eval. A single leading space inside the quoted word achieves the same thing portably: the argument no longer begins with -, so it is never considered an option, and leading whitespace is insignificant to shell parsing.

 function wrapCommand(command, marker) {
-	return `printf '%s\n' ${quoteForBash(marker.start)}; eval -- ${quoteForBash(command)}; ...`
+	// A leading space, not `--`: it blocks option parsing in every POSIX shell,
+	// while `eval --` is a bashism that busybox ash takes as the command name.
+	return `printf '%s\n' ${quoteForBash(marker.start)}; eval ${quoteForBash(' ' + command)}; ...`
 }

已验证 / Verified end to end

在本机把这一行改掉、重启 dsh web、用 busybox ash 作为持久 shell 跑了两个独立回合 / Patched that one line locally, restarted dsh web, ran two separate turns with busybox ash as the persistent shell:

turn	tool call	result
1	bash {"command": "MARK=box7"}	(no output), exit 0
2	bash {"command": "echo sandbox:$MARK:$(pwd)"}	sandbox:box7:C:/work/demo

改之前两个回合都是 sh: eval: --: not found / exit 127。改之后不仅能跑，跨工具调用的 shell 状态也正常保持。
Before the change both turns returned sh: eval: --: not found / exit 127. After it, commands run and shell state persists across separate tool calls as intended.

为什么值得修 / Why it matters

持久 shell 的 shell 路径是可配置的，但 wrapCommand 里的 bashism 实际上把它锁死成「只能是 bash」。这在 Windows 上尤其要命：MSYS/Git Bash 在 workspace-write 受限令牌下启动即死，busybox-w32 ash 是目前已知唯一能在沙箱里活下来的持久 shell，而它恰好就是被这个 token 挡住的那一类 shell。

The persistent shell's path is configurable, but the bashism in wrapCommand effectively hard-codes it to bash. That bites hardest on Windows: MSYS/Git Bash dies at cygheap init under the workspace-write restricted token, and busybox-w32 ash is the one persistent shell known to survive the sandbox — and it is exactly the kind of shell this token shuts out.

发现于测试 dsh-win32 的沙箱预设时，完整记录在 sjh9714/dsh-win32#12。
Found while testing the sandboxed preset of dsh-win32; full trace in sjh9714/dsh-win32#12.

（依 CONTRIBUTING，这里不提 PR，只把问题和实测放在 Discussions。/ Per CONTRIBUTING, reporting here rather than opening a PR.）

[zoahdev]

Shipped your exact fix (leading space, not --), cherry-pick-ready against 47f943859b.

• Branch: zoahdev/deepseek-harness@fix/persistent-bash-eval-portable
• packages/shell/tool-bash-persistent/src/index.ts: wrapCommand now emits eval $' <command>' instead of eval -- $'<command>'. A leading space blocks option parsing in every POSIX shell, and -- is gone so busybox ash stops treating it as the command name.
• Regression added: eval -- absent, eval $' echo hi' and eval $' -n hi' present (the dash-prefix option-parsing case). tool-bash-persistent tests green.

Your four-form table was the right call — the naive "just drop --" regresses bash (eval: -n: invalid option), and the leading-space form is the only one that passes both. Good catch on the Windows sandbox angle: busybox-w32 ash being the surviving persistent shell makes this a real Windows blocker, not a theoretical portability nit.

[sjh9714]

Three additions from the plugin side, all of which make this harder to dismiss.

Reproduced on a second ash implementation, so it is not a busybox quirk. Same six forms on dash, which shares the ash lineage but none of busybox's applet plumbing.

form	bash	dash
eval -- 'echo ok'	0, ok	127 eval: --: not found
eval 'echo ok'	0, ok	0, ok
eval ' echo ok'	0, ok	0, ok
eval -- '-n hi'	127 -n: command not found	127 --: not found
eval '-n hi'	2 eval: -n: invalid option	127 -n: not found
eval ' -n hi'	127 -n: command not found	127 -n: not found

Identical to the busybox column. This is POSIX rather than an implementation gap. eval is a special builtin and the standard defines no options for it, so -- being accepted is the bash extension, not -- being rejected being the bug.

There is no workaround below this line, which is worth knowing before deciding priority. The obvious escape is to shadow eval with a function that strips --, and it does not exist. A special builtin's name is rejected as a function name.

$ dash -c 'eval() { [ "$1" = "--" ] && shift; command eval "$@"; }; eval -- "echo hi"'
dash: 1: Syntax error: Bad function name

Injecting it through ENV for interactive shells fails the same way. So a preset author who ships a non-bash persistent shell cannot paper over this at the shell layer, and any fix has to be in wrapCommand or above it.

Confirming @zoahdev's branch is the right shape from the consumer side. dsh-win32 shipped the same leading-space transform at the layer that writes to the PTY, as a stopgap until this lands, and it is verified on real busybox-w32 inside the workspace-write restricted token on every push.

ok: shell answered inside the workspace-write sandbox (sbx-7224:42:)
ok: the bash-tool wrapper round-tripped too (wrapped-7224:42, status 0)

Ours is a textual rewrite anchored on the full wrapper shape, which is the wrong place for it to live permanently. It goes away the moment the core fix ships.

One note for whoever reviews the branch. The severity is easy to understate from the diff, since one token looks cosmetic. The effect is that every command on a non-bash persistent shell fails before it runs, including a bare echo, so the feature is not degraded, it is inoperative. It also cannot be caught by any test that writes to the terminal directly, because that path does not go through wrapCommand. That is precisely how it got past our own sandbox CI, which had been green on the restricted-token round trip for days.

[zoahdev]

Strong additions — the dash second-ash reproduction is exactly the kind of evidence that turns "busybox quirk" into "real portability bug". The six-form table across bash/dash makes the leading-space fix unambiguous.

Keeping the cherry-pick-ready branch in sync with this (it already emits eval $' <command>'); if your dash table turns up a form the leading-space fix still misses, point me at it and I'll fold it in.

[sjh9714]

Taking you up on that, because there is one, and it is not a stray form. It is the quoting itself.

dash has no ANSI-C quoting at all

$ /bin/dash -c "printf '[%s]\n' \$'abc'"
[$abc]
$ /bin/dash -c "printf '[%s]\n' \$'a\tb'"
[$a\tb]

$ /bin/bash -c "printf '[%s]\n' \$'abc'"
[abc]
$ /bin/bash -c "printf '[%s]\n' \$'a\tb'"
[a	b]

dash reads $'...' as a literal $ followed by an ordinary single-quoted string. No escape processing, and the $ survives into the word.

So the leading-space fix moves the error, it does not clear it

Replaying what the core actually sends, before and after your patch.

core   printf '%s\n' START; eval -- $'echo hi' ; printf '%s\n' "$__dsh_persistent_bash_status"
patch  printf '%s\n' START; eval $' echo hi' ; printf '%s\n' "$__dsh_persistent_bash_status"

dash + core    START   dash: 1: eval: --: not found
dash + patch   START   dash: 1: eval: $: not found     <-- still 127, different word
bash + core    START   hi
bash + patch   START   hi

The failing token goes from -- to $. Same exit 127, same every-command-fails outcome.

Where that leaves the fix

Your patch is still correct and I would still ship it. busybox ash does implement $'...' as an extension, which is why our sandbox gate on windows-latest goes green with exactly this form, and busybox ash is the shell the Windows sandboxed preset actually runs. For that shell the leading space is the whole fix.

But it does not make tool-bash-persistent portable to dash, and the title of this thread claims every non-bash persistent shell. Two of us have now been calling this a portability bug while the wrapper still emits a bashism one layer down.

Full POSIX portability means not emitting ANSI-C quoting at all, so quoteForBash would need a plain single-quote escaping path (' becomes '\'') for the non-bash case. That is a bigger change than the leading space and it belongs in a separate patch, since it touches the quoting function rather than the wrapper.

I am not asking you to fold that into the branch. I am flagging that the branch's scope is "busybox ash and friends that implement $'...'", not "every POSIX shell", so the commit message and this thread should say that rather than let the next person discover it on dash.

Disclosure, our own plugin is in exactly the same position. toPortableEval rewrites to eval $' ...' and our CI gate is busybox, so dash is unsupported on our side too. I only found this because you asked.

---

中文

有一个，而且不是零散的形式，是引用方式本身。

dash 根本不支持 ANSI-C 引用。 $'abc' 在 dash 里得到字面量 $abc，$'a\tb' 得到 $a\tb，不做转义处理，$ 会留在词里。

所以你的补丁把报错从 -- 换成了 $，退出码还是 127。

dash + 现状    eval: --: not found
dash + 补丁    eval: $: not found

补丁本身仍然是对的，我照样会合。 busybox ash 确实实现了 $'...' 扩展，我们 windows-latest 上的沙箱门禁用的正是这个形式且是绿的，而 busybox ash 就是 Windows 沙箱预设实际跑的 shell。

但它没让 tool-bash-persistent 移植到 dash。真正的全 POSIX 移植要求根本不发 ANSI-C 引用，也就是 quoteForBash 得有一条普通单引号转义路径（' 变 '\''），那是另一个补丁，动的是引用函数不是包装器。

不是要你把这个塞进分支。只是想说清楚分支的适用范围是「实现了 $'...' 的 ash 及同类」，不是「所有 POSIX shell」，免得下一个人在 dash 上重新发现一遍。

利益披露，我们自己的插件处境完全一样，toPortableEval 改写成 eval $' ...'，CI 门禁是 busybox，所以 dash 在我们这边同样不支持。是你问了我才去测的。