2013-06-08 36 views
6

Dire che ho questo file.ordinamento con più chiavi con comando di ordinamento Linux

$ cat a.txt 
c 1002 4 
f 1001 1 
d 1003 1 
a 1001 3 
e 1004 2 
b 1001 2 

voglio ordinarlo dalla seconda colonna e poi dalla terza colonna. Le colonne due sono numeri, mentre la colonna 3 può essere trattata come una stringa. So che il seguente comando funziona bene.

$ sort -k2,2n -k3,3 a.txt 
f 1001 1 
b 1001 2 
a 1001 3 
c 1002 4 
d 1003 1 
e 1004 2 

Tuttavia, penso sort -k2n a.txt dovrebbe anche lavorare, mentre non è così.

$ sort -k2n a.txt 
a 1001 3 
b 1001 2 
f 1001 1 
c 1002 4 
d 1003 1 
e 1004 2 

Sembra come ordina dalla colonna due, quindi dalla colonna uno anziché dalla colonna tre. Perché sta succedendo? È un bug o no? Causa sort -k2 a.txt funziona bene con i dati sopra poiché questi numeri sono solo a larghezza fissa.

La mia versione di ordinamento è sort (GNU coreutils) 8.15 in cygwin.

+0

Interessante. 'sort -k2 a.txt' funzionerà in * questo * caso. '-k2' dice di ordinare usando una chiave che inizia al campo 2 e continua fino alla fine della riga. '-k2n' dice di ordinare il campo 2 in ordine numerico; ciò potrebbe significare che la chiave di ordinamento termina incontrando spazi bianchi tra i campi 2 e 3. Potrebbe essere una buona idea incollare la versione del tuo ordinamento nella domanda da qualche parte. –

+0

Uso di 'sort (GNU coreutils) 8.5' Sono in grado di riprodurre il comportamento descritto su Debian stable. – alk

+0

@ MikeSherrill'Catcall 'Quando si tenta di ordinare numericamente un valore non numerico, l'ordinamento (1) torna all'ordinamento delle stringhe. '" 1001 3 "' ecc. Come per '-k2n' sono * non * numerici. – PointedEars

risposta

9

Trovo questa avvertenza nello GNU sort docs.

in ordine numerico sul secondo campo e risolvere i legami di classificare in ordine alfabetico nel terzo e quarto caratteri del campo cinque. Utilizzare ':' come delimitatore di campo.

 sort -t : -k 2,2n -k 5.3,5.4 

Nota che se avessi scritto k 2n invece di k 2,2n sorta avrebbe utilizzati tutti i caratteri a partire dal secondo campo e si estendono fino al fine della linea, come il tasto numerico primaria. Per la grande maggioranza delle applicazioni , il trattamento dei tasti che coprono più di un campo come numerico non farà ciò che ci si aspetta.

Non sono sicuro di cosa finisca quando valuta '1001 3' come un tasto numerico, ma "non farà quello che ci si aspetta" è accurato. Sembra chiaro che la cosa giusta da fare è specificare ogni chiave in modo indipendente.

La stessa pagina web lo dice sulla risoluzione dei "legami".

Infine, come ultima risorsa, quando tutti i tasti risultano uguali, specie a confronto intere linee come se nessuna opzione di ordinazione diversi --reverse (r) erano specificato.

Confesso che sono un po 'sconcertato su come interpretarlo.

+0

L'ultimo paragrafo indica sicuramente che, per tutti i tasti specificati considerati uguali, sort (1) utilizza il confronto di stringhe semplici sulle righe e osserva solo '--reverse' (o' -r') se specificato. Ad esempio, se ci sono delle righe 'foo: 42: bar: baz: blabla' e' foo: 42: baz: bar: blabla', il primo è ordinato prima di quest'ultimo con queste opzioni chiave a causa di '" bar "' < '" baz "', e viceversa se usi '-r'. – PointedEars

+0

Grazie allo sforzo di Mike. Penso che i documenti ordinatori spieghino alcuni. Dovremmo solo fare attenzione a considerare i tasti che coprono più di un campo come numerici. – yejinxin

+0

@PointedEars: questo spiegherebbe il comportamento, penso. Ordina prima il tasto, poi l'intera riga. L'intera linea, ovviamente, inizia con il primo campo. –

Problemi correlati