GNU coreutils sort 的行為不同

我想對數據列表進行排序，並打算根據其第一列（即 IP 地址）對其進行排序。

192.168.1.100
192.168.1.101
192.168.1.110
192.168.1.119
192.168.1.20
192.168.1.30
192.168.1.33
192.168.1.54
192.168.1.64
192.168.1.6
192.168.1.91

在我的第一台機器上，我進行了測試sort -n，它按預期工作

# coreutils, version: 8.31, release: 23

192.168.1.6
192.168.1.20
192.168.1.30
192.168.1.33
192.168.1.54
192.168.1.64
192.168.1.91
192.168.1.100
192.168.1.101
192.168.1.110
192.168.1.119

但是在我的第二台機器上，它不能正確排序

# coreutils, version:8.4

192.168.1.100
192.168.1.101
192.168.1.110
192.168.1.119
192.168.1.20
192.168.1.30
192.168.1.33
192.168.1.54
192.168.1.6
192.168.1.64
192.168.1.91

兩台機器具有相同的語言環境en_US.UTF-8

---

為什麼會這樣？我該如何解決？

如果沒有適當的鍵位，sort則使用整行作為鍵。由於在所有行中，前三個八位字節保持不變，因此整個排序基於最後一個八位字節中第一個字元的數字位置。由於1出現在2帶有 的八位字節之前100，因此101出現在其他八位字節之前。

定義正確的關鍵位置並使用數字排序。例如，在您的情況下，將輸入的分隔符設置為，.並讓其sort僅在第 4 個欄位上發揮作用。4,4方法從由 分隔的第 4 個欄位開始並.在相同的第 4 個欄位停止。

sort -n -t'.' -k4,4 file

您還可以覆蓋locale系統中定義的任何其他設置，並直接使用系統的預設設置和LC_ALL=C本地命令。請參閱做什麼LC_ALL=C？了解為什麼

LC_ALL=C sort -n -t'.' -k4,4 file

感謝Kamil Maciorowski 的評論突出了實際問題。

第一台機器似乎正在使用locale thousands_sep返回的語言環境.可能不是en_US.UTF-8（至少不是 as LC_NUMERIC）。第二台機器不用.作千位分隔符。

引用自：https://unix.stackexchange.com/questions/566723