在這個問題有一則評論說：
這一切都源自於不理解「在 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” 。
除了使用者互動之外，這表明系統確實需要以所有系統通用的可預測方式運作。