[Bug] macOS 上 bash 工具执行含中文命令会损坏并超时（bash 3.2 PTY 数据损坏）

[meizhou0228]

问题现象

在 macOS 上，DSH 的 bash 工具执行含中文（非 ASCII）的命令时，命令会被损坏并最终超时：

• echo 中文测试 实际输出 --------（中文被替换成 8 个连字符，与字符数无关）。
• git commit -m '优化下载命名' 这类含中文的命令会一直卡到 300s 超时（timed out after 300 seconds），期间 bash 不打印完成标记、也不回到 dsh> 提示符。

环境

• OS：macOS (arm64)
• /bin/bash --version：GNU bash, version 3.2.57(1)-release (arm64-apple-darwin25)
• DSH：0.1.0-rc.7（packages/shell/tool-bash-persistent + packages/terminal/terminal-bash）
• node-pty：1.2.0-beta.15

根因

这是 node-pty 已知的 macOS bash 3.2 readline 数据损坏问题（node-pty issue #833）。node-pty 源码 unixTerminal.js 里的注释也明确写了：

old versions of bash, like v3.2 which ships in macOS, appears to have a bug in its readline implementation that causes data corruption when writes to the pty happens too quickly ... we just accept it

DSH 的 tool-bash-persistent 会把整条命令一次性快速写入 PTY，macOS 自带的 bash 3.2 在快速写入时损坏非 ASCII（多字节 UTF-8）字节，导致：

1. 命令里的中文变成 -（实测 1~4 个中文字符都固定变成 8 个 -）；
2. 命令字节流被打乱，bash 无法正常执行完，__DSH_PERSISTENT_BASH_END_* 标记不打印、也不回到 dsh> 提示符；
3. DSH 轮询不到完成信号，一直等到 300s 工具级超时并 reset shell。

纯 ASCII 命令不受影响；printf '\\xe4\\xb8\\xad' 这类在 bash 端生成中文的写法也不受影响（命令本身仍是纯 ASCII）。

修复方案

在 quoteForBash 里把命令中的非 ASCII 字节（>= 0x80）转义成 ANSI-C 的 \xHH，让写入 PTY 的命令保持纯 ASCII，从而规避 bash 3.2 的 readline 损坏：

import { Buffer } from 'node:buffer'

function quoteForBash(value: string): string {
  const escaped = value
    .replaceAll('\\', '\\\\')
    .replaceAll("'", "\\'")
    .replaceAll('\r', '\\r')
    .replaceAll('\n', '\\n')
  let out = ''
  for (const byte of Buffer.from(escaped, 'utf8')) {
    if (byte >= 0x80) {
      out += `\\x${byte.toString(16).padStart(2, '0')}`
    } else {
      out += String.fromCharCode(byte)
    }
  }
  return `$'${out}'`
}

验证

• echo 中文测试 转义后为纯 ASCII：$'echo \xe4\xb8\xad\xe6\x96\x87\xe6\xb5\x8b\xe8\xaf\x95'
• 经真实 bash 执行 eval -- ... 能正确输出 中文测试，退出码 0
• 纯 ASCII 命令（如 echo hi）输出不变，无回归影响
• node --check 通过

希望能帮到团队修复这个问题。

[denial123789]

I traced this against the 0.1.0-rc.7 source path. The important distinction is that the timeout appears to be a consequence, not the first failure: the persistent Bash tool wraps the command with start/end markers, sends the complete wrapped string through a single terminal write, and then waits for the end marker. If non-ASCII bytes are damaged before Bash parses them, the expected marker may never arrive and the tool eventually reports a timeout.

At the pinned commit, quoteForBash escapes backslashes, quotes, CR, and LF, but has no non-ASCII transport branch. The terminal session appends CR and forwards the whole string in one write. That matches the macOS Bash 3.2 reproduction closely enough to make transport/serialization the first boundary I would instrument.

Practical bounded workarounds:

1. Use a one-shot local Bash execution path when the profile exposes one.
2. For controlled inputs, transform non-ASCII UTF-8 bytes into reviewed ASCII \\xHH escapes before they cross the PTY boundary.
3. Use a custom profile with a newer Bash and rerun a multilingual regression matrix.

A durable repair belongs at the serializer boundary: preserve ASCII as-is and encode each non-ASCII UTF-8 byte as \\xHH, then verify CJK, emoji, combining marks, quotes, newlines, and marker-like text. Increasing the timeout alone can hide the symptom without preserving the command.

I documented the evidence chain, recovery choices, and regression gates here: https://sandbaseai.github.io/deepseek-harness-handbook/macos-bash-nonascii.html

Disclosure: this is an independent community handbook maintained by SandBase, not an official DeepSeek document.