observe a diferença na saída entre esses dois pipelines:
<yourexample \
sort -t\; -gk26 |
cut -d\; -f26
-7.18901342e+02
-7.78309996e+01
-9.38492178e+02
-7.78321216e+01
-7.78326108e+01
-7.78317280e+01
-7.78322942e+01
-7.78322863e+01
-7.61265100e+02
... e ...
<yourexample \
sort -t\; -gk26,26 |
cut -d\; -f26
-9.38492178e+02
-7.61265100e+02
-7.18901342e+02
-7.78326108e+01
-7.78322942e+01
-7.78322863e+01
-7.78321216e+01
-7.78317280e+01
-7.78309996e+01
classificar apenas em -k
ey 26 é o mesmo que classificar da chave 26 até o final da linha, mas classificando em -k
ey 26, 26 classifica somente nessa chave. Se você quiser considerar outros campos na ordem de classificação como desempatadores, adicione mais -k
eys - mas seja específico.
Além disso, você comentou você está trabalhando com um pacote GNU Coreutils de 5 anos de idade . Curioso, eu pulei alguns changelogs após o seu lançamento, e isso se destacou dentro de dois lançamentos (outubro) 2010 for v8.6) :
sort -g
now uses long doubles for greater range and precision.
sort -h
no longer rejects numbers with leading or trailing.
, and no longer accepts numbers with multiple.
. It now considers all zeros to be equal.
Você pode atualizar.