为何管道中带readline的程序用&>重定向会异常，单独1>/2>则正常

• readline提示符长度计算规则适配错误：readline要求所有放入提示符的不可打印字符（比如你代码中使用的WHITE、RESET这类ANSI颜色转义序列）必须用\001（ASCII SOH）和\002（ASCII STX）包裹，用于标识这部分内容不会占用终端显示宽度。你代码中没有添加该包裹逻辑，readline会将转义序列的字节长度也算作提示符的显示宽度，导致内部光标位置计算完全错误。
• 标准流缓冲模式不一致：stdout的默认缓冲规则为「输出到终端时行缓冲，输出到非终端（文件/管道）时全缓冲，默认缓冲区大小通常为4KB」，而stderr无论任何场景都是无缓冲的。当你使用&>将stdout和stderr重定向到同一个文件时，两个流的内核态文件偏移是共享的，但用户态缓冲完全独立、写入时机不同步：stderr的内容会直接写入文件推进偏移，stdout的内容要等缓冲区满、手动刷缓或进程退出时才会写入，天然会出现内容穿插的问题。
• 非交互场景下控制字符异常输出：当stdin是管道（非终端）时，readline进入非交互模式，但是因为之前的提示符长度计算错误，它会误判光标位置，输出\r（回车符，将光标移动到行首）、退格符等控制字符尝试修正光标位置。这些控制字符和正常输出内容混合在stdout缓冲区，进程退出刷缓后就会出现行首内容被覆盖、输出乱序的问题。

短提示符场景下未触发异常，是因为短提示符加转义序列的总长度较小，readline计算的光标偏移误差没有达到触发控制字符输出的阈值，同时整体输出内容没有超过stdout全缓冲的阈值，进程退出时一次性刷入文件的内容顺序刚好符合预期。原生bash没有该问题，是因为bash内部严格遵守readline的转义包裹规则，且在非交互模式下会主动关闭readline的提示符输出逻辑，改用直接写入标准流的逻辑规避缓冲冲突。

内容的提问来源于stack exchange，提问作者hugogogo