在这个问题有一条评论说：
所有这一切都源于不理解“在 POSIX 语言环境中”的含义。 （-：你真的应该尝试将希腊小写字母与（例如）sed 和 [[:lower:]] 以及方便的 el_GR.UTF-8 区域设置相匹配。 – JdeBP
那么：“在 POSIX 语言环境中”是什么意思？
额外奖励：这在 C 以外的语言环境中的 POSIX 中有效吗？
LC_ALL=C grep '[[:lower:]]' file
答案1
当 POSIX 说（“上”）时
在 POSIX 语言环境中，仅：
ABCDEFGHIJKLMNOPQRSTU VWXYZ
应包括：
它定义了 POSIX 语言环境。这意味着在 POSIX 语言环境的上下文中，“上部”字符类仅包含列出的字符。
POSIX 没有定义任何其他语言环境，但系统可以自由地这样做。因此，grep '[[:lower:]]' file如果您将自己限制为仅使用 POSIX，那么您就不能依赖在 POSIX 以外的语言环境中执行任何有用的操作。然而，许多系统确实定义了其他语言环境及其字符类。例如，在使用 GNU C 库语言环境的系统上，
$ echo 'α' | LC_ALL=el_GR.UTF-8 grep '[[:lower:]]'
α
（这假设el_GR.UTF-8语言环境可用；在 Debian 衍生版本上，确保这一点的快速方法是安装软件包locales-all。）
答案2
我还没有完全理解你的建议（在另一个问题中）。然而，您似乎误解了用例POSIX 语言环境。
您的建议似乎是区域设置不是很用户友好的。并且应该对其进行调整以实现这一目标。然而用户友好不是 posix local 的重点，这是具有其他规则的其他语言环境的工作。
posix local 的工作是可预测的。事实上，它也受益于简单。一旦开始将其他语言纳入标准中，就很难停下来，结果是标准需要大量维护并且难以实施。
作为一名开发人员，我不可能知道每种语言的每条规则，如何按“字母顺序”对它们进行排序，并且确实知道哪些是大写或小写。非英语语言的规则确实非常复杂。因此，如果您调整 Posix local 以包含所有其他语言的规则，那么您实际上会使其行为变得非常不可预测。
对 posix 语言环境的更改确实可能会对旧系统与新系统的行为不匹配的软件造成损害。 （参见下面的轶事）
轶事
我见过的最晦涩难懂、最难诊断的错误之一是在ETL工具“随机”删除行。经过艰苦的分析，发现该软件运行良好，但前提是使用 LC_COLLATE=C 运行。这是因为，在匹配记录时，它依赖于数据库中与其自身内部排序顺序相匹配的排序顺序。开发人员根本没有注意到，在某些区域设置中，数字会按字母顺序对文本进行排序“0, -1, 1, -2, 2”，而不是“-1, -2, 1, 2”。
除了用户交互之外，这表明系统确实需要以所有系统通用的可预测方式运行。