Sort & uniq dans le shell Linux
Quelle est la différence entre les commandes suivantes?
sort -u FILE
sort FILE | uniq
6 réponses
utilisant sort -u fait moins d'E/S que sort | uniq , mais le résultat final est le même. En particulier, si le fichier est assez grand que sort doit créer des fichiers intermédiaires, il y a une chance décente que sort -u utilisera un peu moins ou des fichiers intermédiaires légèrement plus petits car il pourrait éliminer les doublons car il est le tri de chaque ensemble. Si les données sont très dupliquées, cela pourrait être bénéfique; s'il y a peu de doublons en fait, cela ne fera pas beaucoup de différence (certainement un effet de performance de deuxième ordre, par rapport à l'effet de premier ordre de la pipe).
noter qu'il y a des moments où la tuyauterie est appropriée. Par exemple:
sort FILE | uniq -c | sort -n
il trie les fichiers dans l'ordre du nombre d'occurrences de chaque ligne dans le fichier, avec le plus répété lignes apparaissant en dernier. (Cela ne me surprendrait pas de constater que cette combinaison, qui est idiomatique pour Unix ou POSIX, peut être écrasée en un " tri " complexe commande avec GNU sort.)
il y a des moments où ne pas utiliser le tuyau est important. Par exemple:
sort -u -o FILE FILE
cela trie le fichier" in situ"; c'est-à-dire que le fichier de sortie est spécifié par -o FILE , et cette opération est garantie sûre (le fichier est lu avant d'être écrasé pour la sortie).
il y a une légère différence: le code de retour.
le truc c'est qu'à moins que shopt -o pipefail ne soit défini le code de retour de la commande pipée sera le code de retour du dernier. Et uniq retourne toujours zéro (succès). Essayez d'examiner le code de sortie, et vous verrez quelque chose comme ceci ( pipefail n'est pas défini ici):
pavel@lonely ~ $ sort -u file_that_doesnt_exist ; echo $?
sort: open failed: file_that_doesnt_exist: No such file or directory
2
pavel@lonely ~ $ sort file_that_doesnt_exist | uniq ; echo $?
sort: open failed: file_that_doesnt_exist: No such file or directory
0
à part cela, les commandes sont équivalentes.
attention! Bien qu'il soit vrai que "sort-u" et "sort|uniq" sont équivalents, toute option supplémentaire pour trier peut briser l'équivalence. Voici un exemple du manuel coreutils:
par exemple, "sort-n-u" inspecte seulement la valeur de la chaîne numérique initiale lors du contrôle de l'unicité, tandis que "sort-n | uniq" inspecte la ligne entière.
de même, si vous triez sur les champs clés, le test d'unicité utilisé par le sort ne regardera plus nécessairement toute la ligne. Après avoir été mordu par ce bug dans le passé, ces jours-ci j'ai tendance à utiliser "sort|uniq" quand j'écris des scripts Bash. Je préfère avoir plus de frais généraux d'E/S que courir le risque que quelqu'un d'autre dans le magasin ne sera pas au courant de ce piège particulier quand ils modifient mon code pour ajouter des paramètres de tri supplémentaires.
sort -u sera légèrement plus rapide, parce qu'il n'a pas besoin de Piper la sortie entre deux commandes
voir aussi ma question sur le thème: appeler uniq et trier dans différents ordres dans shell
j'ai travaillé sur certains serveurs où sort ne supporte pas l'option '-u'. là, nous devons utiliser
sort xyz | uniq