sort column linux shell sorting uniq

column - sort linux



Sort & uniq en shell de Linux (6)

¡Tener cuidado! Si bien es cierto que "sort -u" y "sort | uniq" son equivalentes, cualquier opción adicional para ordenar puede romper la equivalencia. Aquí hay un ejemplo del manual de coreutils:

Por ejemplo, ''sort -n -u'' inspecciona solo el valor de la cadena numérica inicial cuando busca la unicidad, mientras que ''sort -n | uniq ''inspecciona toda la línea.

De forma similar, si clasifica los campos clave, la prueba de unicidad utilizada por clasificación ya no necesariamente revisará toda la línea. Después de haber sido mordido por ese error en el pasado, en estos días tiendo a usar "sort | uniq" cuando escribo scripts Bash. Prefiero tener una mayor sobrecarga de E / S que correr el riesgo de que alguien más en la tienda no sepa acerca de esa trampa en particular cuando modifiquen mi código para agregar parámetros de clasificación adicionales.

¿Cuál es la diferencia entre los siguientes comandos?

sort -u FILE sort FILE | uniq

Hay una pequeña diferencia: código de retorno.

El problema es que, a menos que shopt -o pipefail esté configurado, el código de retorno del comando canalizado será el código de retorno del último. Y uniq siempre devuelve cero (éxito). Intenta examinar el código de salida y verás algo como esto ( pipefail no está establecido aquí):

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

Aparte de esto, los comandos son equivalentes.

He trabajado en algunos servidores donde sort no admite la opción ''-u''. allí tenemos que usar

sort xyz | uniq

Nada, producirán el mismo resultado

Usar sort -u hace menos E / S que sort | uniq sort | uniq , pero el resultado final es el mismo. En particular, si el archivo es lo suficientemente grande como para que el sort tenga que crear archivos intermedios, existe una posibilidad decente de que los archivos intermedios sort -u usarán un poco menos o un poco más pequeño ya que podría eliminar los duplicados a medida que ordena cada conjunto. Si los datos son altamente duplicativos, esto podría ser beneficioso; si hay pocos duplicados de hecho, no hará mucha diferencia (definitivamente un efecto de rendimiento de segundo orden, en comparación con el efecto de primer orden de la tubería).

Tenga en cuenta que hay momentos en que la tubería es apropiada. Por ejemplo:

sort FILE | uniq -c | sort -n

Esto ordena el archivo en orden de la cantidad de apariciones de cada línea en el archivo, apareciendo las líneas más repetidas al final. (No me sorprendería descubrir que esta combinación, que es idiomática para Unix o POSIX, se puede agrupar en un complejo comando de ''ordenación'' con clasificación GNU).

Hay momentos en que no usar la tubería es importante. Por ejemplo:

sort -u -o FILE FILE

Esto ordena el archivo ''in situ''; es decir, el archivo de salida está especificado por -o FILE , y esta operación está garantizada de forma segura (el archivo se lee antes de sobrescribirse para la salida).