2010-08-01 67 views
36

以下命令與以下命令有什麼區別?Linux shell中的排序和uniq

sort -u FILE 

sort FILE | uniq 
+0

當你跑他們,你看到了什麼?您是否嘗試收集不同大小文件的時間差異?您可以運行一些實驗併發布結果是您問題的一部分。 – 2010-08-01 17:08:50

+0

我想知道是否有一個特殊情況是兩個命令的行爲不同,在正常執行中他們都給出了相同的結果 – yassin 2010-08-01 17:12:39

+3

[「sort -u」和「sort | uniq「?](http://unix.stackexchange.com/q/76049/17265) – mtk 2014-04-15 10:04:24

回答

59

使用sort -usort | uniq少I/O,但最終結果是相同的。尤其是,如果文件足夠大以至於sort必須創建中間文件,那麼sort -u將使用略少或略小的中間文件,因爲它可以消除重複,因爲它會對每個文件集進行排序。如果數據高度重複,這可能是有益的;如果實際上有很少的重複,它不會產生太大的差別(絕對是二階效果,與管道的一階效應相比)。

請注意,有時管道是適當的。例如:

sort FILE | uniq -c | sort -n 

將文件按照文件中每行出現次數的順序排序,最後出現最多重複的行。 (我不覺得這個組合是Unix還是POSIX的習慣用法,可以用GNU排序將它們壓縮成一個複雜的「排序」命令。)

有時候不使用管道很重要。例如:

sort -u -o FILE FILE 

這樣排序文件'in situ';即輸出文件由-o FILE指定,並且此操作保證安全(文件在被覆蓋輸出前被讀取)。

+0

感謝您的完整答案! – yassin 2010-08-01 17:31:12

+0

gnu sort沒有辦法完成'sort |的所有操作uniq -c | sort -n',而且我也沒有找到任何其他工具來有效地完成它。似乎是一個有價值的代碼。 – mc0e 2015-02-18 16:23:52

2

沒有什麼,他們會產生相同的結果

10

有一點區別:返回碼。

問題是,除非設置了shopt -o pipefail,否則管道命令的返回碼將是最後一個的返回碼。並且uniq總是返回零(成功)。嘗試檢查退出代碼,你會看到這樣的事情(pipefail此處未設置):

[email protected] ~ $ sort -u file_that_doesnt_exist ; echo $? 
sort: open failed: file_that_doesnt_exist: No such file or directory 
2 
[email protected] ~ $ sort file_that_doesnt_exist | uniq ; echo $? 
sort: open failed: file_that_doesnt_exist: No such file or directory 
0 

除此之外,該命令是等價的。

0

我曾在一些服務器上排序不支持'-u'選項。我們必須使用

sort xyz | uniq 
+1

您是否願意指定哪個服務器具有哪個o/s版本以及何時?第七版UNIX™'sort'支持'-u',這是第一個被廣泛使用的UNIX版本,因此所有其他版本(系統III,系統V,BSD等)都傾向於遵循它,所以我會很驚訝找到'sort'不支持'-u'的類Unix系統。 – 2012-12-27 15:05:09

6

當心!儘管「sort -u」和「sort | uniq」是等價的,但是排序的其他選項可能會打破等價。下面是coreutils手冊中的一個示例:

例如,'sort -n -u'在檢查唯一性時僅檢查初始數字字符串的值,而'sort -n | uniq'檢查整條生產線。

同樣,如果您在關鍵字段上排序,排序使用的唯一性測試不一定會看到整個行。在過去被這個錯誤困擾之後,這些日子我傾向於在編寫Bash腳本時使用「sort | uniq」。我寧願有更高的I/O開銷,也不願冒着他們修改我的代碼來添加額外的排序參數時,商店中的其他人不知道該特定陷阱的風險。