Bash 为什么从我的脚本中删除所有NUL？

它看起来像bash，也像dash，从我的脚本中过滤掉任何ASCII NUL

$ printf 'test="\000a" ; echo ${#test}' | sh
1
$ printf 'test="\001a" ; echo ${#test}' | sh
2
$ printf 'ec\000ho test' | sh
test
$ # (Same for bash)

虽然我同意使用NUL是一个坏主意（例如，传递给程序的参数使用NUL终止的字符串），但我看不出这一行为在哪里受到法律的制裁

当这种行为决定文件的语法正确性时，情况会变得更糟

$ printf 'echo "\\\000"' | sh
sh: Syntax error: Unterminated quoted string
$ printf 'echo "\\\000"' | bash
bash: line 1: unexpected EOF while looking for matching `"'
bash: line 2: syntax error: unexpected end of file
$ printf 'echo "\\\134"' | sh
\

---

我遗漏了什么重要部分，或者NUL的删除只是一个关于如何处理未指定行为的决定？

州标准中的输入文件部分：

输入文件应为文本文件，但行长度不受限制。如果输入文件为空或仅由空行或注释组成，或两者兼而有之，sh应以零退出状态退出

术语“文本文件”在第3.395节中定义为：

包含组织成零行或多行的字符的文件。这些行不包含NUL字符，任何行的长度都不能超过{LINE_MAX}字节，包括字符。尽管POSIX.1-2008没有区分文本文件和二进制文件（参见ISO C标准），但许多实用程序在对文本文件进行操作时只会产生可预测或有意义的输出。具有此类限制的标准实用程序总是在其STDIN或INPUT files部分中指定“文本文件”

---

如果输入不是文本文件（如果它包含零字节，则不是文本文件），则该行为既没有意义也不可预测。

我熟悉的所有sh实现都使用C字符串，这些字符串（以NUL结尾）本质上无法保存NUL值。zsh可以很好地处理所有这些测试用例。我还可以尝试询问Unix和Linux，如果@CharlesDuffy的答案还不够。我正在查看POSIX规范，令人惊讶的是，我没有看到任何禁止使用

NUL

@AlanCurry:Try

printf'test=“\000”；printf“$test”| wc-c'| zsh

然后

printf'test=“\000”/usr/bin/printf“$test”| wc-c'| zsh

。不太好：-）+1似乎是我要找的。这意味着，我认为最好建议在NUL上中止实现。