shell - Bourne Shell 源代码中的 Unicode

Question

在现代 Bourne Shell 解释器中使用 UTF-8 而不仅仅是 7 位 ASCII 子集是否安全，无论是在注释中（例如，使用画框字符），还是通过将参数传递给函数或程序？我正在考虑文件系统是否可以安全地处理此问题范围之外的路径名中的 Unicode。

我知道至少不要在我的 shell 脚本中放置 BOM……因为这会破坏内核的 shebang 行解析。

Answer 1

关于 UTF-8 的事情是，任何只是传递字符串数据并使用 C 字符串约定以空字节终止字符串的任何旧代码都可以正常工作。这通常表征了 shell 如何处理命令名称和参数。

即使 shell 对 ascii 字符进行了一些具有特殊含义的字符串处理，UTF-8 仍然可以正常工作，因为 ascii 字符在 UTF-8 中编码完全相同。因此，例如，shell 仍将能够识别其所有关键字和语法字符等[]{}()<>/.?;'"$&*。例如，这表征了字符串文字和脚本的其他语法位应如何处理。

您应该能够在注释、字符串文字、命令名称和命令参数中使用 UTF-8。（当然，系统必须支持 UTF-8 文件名才能具有 UTF-8 命令，并且这些命令必须处理 UTF-8 命令行参数。）

您可能无法在函数名或变量中使用 UTF-8，因为 shell 可能正在那里寻找 ascii 字符串。尽管如果您的语言环境是 UTF-8，那么在内部使用基于语言环境的字符分类函数的解释器也可能与 UTF-8 标识符一起使用，但它可能不可移植。

Answer 2

这真的取决于你想要做什么......一般来说，普通的香草 Bourne 派生的 shell 无法处理脚本中的 Unicode 字符，这意味着如果你关心可移植性，你的脚本文本必须是纯 8 位 ASCII(+)。同时管道完全编码中性，因此您可以拥有输出 UTF-8 并接收它的a | b地方。因此，假设能够处理 UTF-8 路径并且您的处理工具可以处理 UTF-8 字符串，那么您应该没问题。abfind

Answer 3

多字节支持是在 1989 年添加到 Bourne Shell 中的，并且鉴于 UNICODE 是在 1992 年引入的，因此您不能期望 UTF-8 来自比 UNICODE 更早的 shell。SunOS 在可用时引入了 UNICODE 支持。

因此，任何从 SVr4 Bourne Shell 派生并编译并链接到现代库环境的 Bourne Shell 都应该在脚本中支持 UTF-8。

如果您想验证这一点，您可以从 schily-tools 中的 OpenSolaris Bourne Shell 获得可移植版本：http: //sourceforge.net/projects/schilytools/files/

osh是原始的 Bourne Shell，仅可携带。

sh是具有现代增强功能的 Bourne Shell。