Sorting numericallyHow to sort by multiple columns?Sorting data faster approachHow to sort lines that contain “_” numerically?Sort unix alphabetically then numerically, not working as I intendedSorting filenamesCan you sort one column lexicographically while simultaneously sorting the next column numerically?Sorting numerically by character field position within fieldsort a list numerically and alphabetically
Has my MacBook been hacked?
Performance for simple code that converts a RGB tuple to hex string
The quicker I go up, the sooner I’ll go down - Riddle
I reverse the source code, you negate the input!
Social leper versus social leopard
1, 2, 4, 8, 16, ... 33?
What's the story to "WotC gave up on fixing Polymorph"?
How do I deal with too many NPCs in my campaign?
What benefits does the Power Word Kill spell have?
I reverse the source code, you negate the output!
What is the lowest voltage that a microcontroller can successfully read on the analog pin?
Idiom for "I came, I saw, I ate" (or drank)
How do I improve in sight reading?
Would Taiwan and China's dispute be solved if Taiwan gave up being the Republic of China?
How to manage expenditure when billing cycles and paycheck cycles are not aligned?
Is it a good idea to leave minor world details to the reader's imagination?
Guitar tuning (EADGBE), "perfect" fourths?
How to make interviewee comfortable interviewing in lounge chairs
The 100 soldier problem
Do we know the situation in Britain before Sealion (summer 1940)?
Why does rhenium get a pass on being radioactive?
What are these ingforms of learning?
Is the mass of paint relevant in rocket design?
Leaving a job that I just took based on false promise of a raise. What do I tell future interviewers?
Sorting numerically
How to sort by multiple columns?Sorting data faster approachHow to sort lines that contain “_” numerically?Sort unix alphabetically then numerically, not working as I intendedSorting filenamesCan you sort one column lexicographically while simultaneously sorting the next column numerically?Sorting numerically by character field position within fieldsort a list numerically and alphabetically
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I have a file called data
whose contents are
id,col1,col2
0,-0.3479417882673812,0.5664382596767175
1,-0.26800930980980764,0.2952025161991604
2,-0.4159790791116641,-1.3375045524610152
3,-0.7859665489205871,-0.6428101880909471
4,-1.3922759043388822,-1.676262144826317
5,-1.2471867496427498,-0.4912119581361516
6,1.443385383041667,1.6974039491263593
7,-2.058899802821969,2.0607628464079917
8,-0.10641338441541626,0.035929568275064216
9,-0.517273684861199,-0.6184800988804992
10,-0.9934859021679552,1.0577312348984502
11,0.5923834706792905,-0.6693757541250825
12,0.8657741917554445,-0.6876271057571398
13,-1.2061097548360489,-0.7402582563022937
14,0.78768021182158,-0.38607117005262315
Sorting numerically (-n
) on the first column gives
$ sort -nk1 -t"," data
0,-0.3479417882673812,0.5664382596767175
id,col1,col2
1,-0.26800930980980764,0.2952025161991604
2,-0.4159790791116641,-1.3375045524610152
3,-0.7859665489205871,-0.6428101880909471
4,-1.3922759043388822,-1.676262144826317
5,-1.2471867496427498,-0.4912119581361516
7,-2.058899802821969,2.0607628464079917
8,-0.10641338441541626,0.035929568275064216
9,-0.517273684861199,-0.6184800988804992
10,-0.9934859021679552,1.0577312348984502
13,-1.2061097548360489,-0.7402582563022937
6,1.443385383041667,1.6974039491263593
11,0.5923834706792905,-0.6693757541250825
12,0.8657741917554445,-0.6876271057571398
14,0.78768021182158,-0.38607117005262315
This absolutely bizarre to me. I read in the man page that -n
is supposed to be numerical sort. Why would id
be placed in-between numbers? How is it that 10
is larger than 9
, but smaller than 6
, all the while 11
being greater than them all?
The -g
seems to work as I want (and as I think is natural), but this -n
option totally escapes me. What's this about? I think it can be related to locale, but once I specify the delimiter as being ,
, I don't think that would explain it.
sort
add a comment
|
I have a file called data
whose contents are
id,col1,col2
0,-0.3479417882673812,0.5664382596767175
1,-0.26800930980980764,0.2952025161991604
2,-0.4159790791116641,-1.3375045524610152
3,-0.7859665489205871,-0.6428101880909471
4,-1.3922759043388822,-1.676262144826317
5,-1.2471867496427498,-0.4912119581361516
6,1.443385383041667,1.6974039491263593
7,-2.058899802821969,2.0607628464079917
8,-0.10641338441541626,0.035929568275064216
9,-0.517273684861199,-0.6184800988804992
10,-0.9934859021679552,1.0577312348984502
11,0.5923834706792905,-0.6693757541250825
12,0.8657741917554445,-0.6876271057571398
13,-1.2061097548360489,-0.7402582563022937
14,0.78768021182158,-0.38607117005262315
Sorting numerically (-n
) on the first column gives
$ sort -nk1 -t"," data
0,-0.3479417882673812,0.5664382596767175
id,col1,col2
1,-0.26800930980980764,0.2952025161991604
2,-0.4159790791116641,-1.3375045524610152
3,-0.7859665489205871,-0.6428101880909471
4,-1.3922759043388822,-1.676262144826317
5,-1.2471867496427498,-0.4912119581361516
7,-2.058899802821969,2.0607628464079917
8,-0.10641338441541626,0.035929568275064216
9,-0.517273684861199,-0.6184800988804992
10,-0.9934859021679552,1.0577312348984502
13,-1.2061097548360489,-0.7402582563022937
6,1.443385383041667,1.6974039491263593
11,0.5923834706792905,-0.6693757541250825
12,0.8657741917554445,-0.6876271057571398
14,0.78768021182158,-0.38607117005262315
This absolutely bizarre to me. I read in the man page that -n
is supposed to be numerical sort. Why would id
be placed in-between numbers? How is it that 10
is larger than 9
, but smaller than 6
, all the while 11
being greater than them all?
The -g
seems to work as I want (and as I think is natural), but this -n
option totally escapes me. What's this about? I think it can be related to locale, but once I specify the delimiter as being ,
, I don't think that would explain it.
sort
add a comment
|
I have a file called data
whose contents are
id,col1,col2
0,-0.3479417882673812,0.5664382596767175
1,-0.26800930980980764,0.2952025161991604
2,-0.4159790791116641,-1.3375045524610152
3,-0.7859665489205871,-0.6428101880909471
4,-1.3922759043388822,-1.676262144826317
5,-1.2471867496427498,-0.4912119581361516
6,1.443385383041667,1.6974039491263593
7,-2.058899802821969,2.0607628464079917
8,-0.10641338441541626,0.035929568275064216
9,-0.517273684861199,-0.6184800988804992
10,-0.9934859021679552,1.0577312348984502
11,0.5923834706792905,-0.6693757541250825
12,0.8657741917554445,-0.6876271057571398
13,-1.2061097548360489,-0.7402582563022937
14,0.78768021182158,-0.38607117005262315
Sorting numerically (-n
) on the first column gives
$ sort -nk1 -t"," data
0,-0.3479417882673812,0.5664382596767175
id,col1,col2
1,-0.26800930980980764,0.2952025161991604
2,-0.4159790791116641,-1.3375045524610152
3,-0.7859665489205871,-0.6428101880909471
4,-1.3922759043388822,-1.676262144826317
5,-1.2471867496427498,-0.4912119581361516
7,-2.058899802821969,2.0607628464079917
8,-0.10641338441541626,0.035929568275064216
9,-0.517273684861199,-0.6184800988804992
10,-0.9934859021679552,1.0577312348984502
13,-1.2061097548360489,-0.7402582563022937
6,1.443385383041667,1.6974039491263593
11,0.5923834706792905,-0.6693757541250825
12,0.8657741917554445,-0.6876271057571398
14,0.78768021182158,-0.38607117005262315
This absolutely bizarre to me. I read in the man page that -n
is supposed to be numerical sort. Why would id
be placed in-between numbers? How is it that 10
is larger than 9
, but smaller than 6
, all the while 11
being greater than them all?
The -g
seems to work as I want (and as I think is natural), but this -n
option totally escapes me. What's this about? I think it can be related to locale, but once I specify the delimiter as being ,
, I don't think that would explain it.
sort
I have a file called data
whose contents are
id,col1,col2
0,-0.3479417882673812,0.5664382596767175
1,-0.26800930980980764,0.2952025161991604
2,-0.4159790791116641,-1.3375045524610152
3,-0.7859665489205871,-0.6428101880909471
4,-1.3922759043388822,-1.676262144826317
5,-1.2471867496427498,-0.4912119581361516
6,1.443385383041667,1.6974039491263593
7,-2.058899802821969,2.0607628464079917
8,-0.10641338441541626,0.035929568275064216
9,-0.517273684861199,-0.6184800988804992
10,-0.9934859021679552,1.0577312348984502
11,0.5923834706792905,-0.6693757541250825
12,0.8657741917554445,-0.6876271057571398
13,-1.2061097548360489,-0.7402582563022937
14,0.78768021182158,-0.38607117005262315
Sorting numerically (-n
) on the first column gives
$ sort -nk1 -t"," data
0,-0.3479417882673812,0.5664382596767175
id,col1,col2
1,-0.26800930980980764,0.2952025161991604
2,-0.4159790791116641,-1.3375045524610152
3,-0.7859665489205871,-0.6428101880909471
4,-1.3922759043388822,-1.676262144826317
5,-1.2471867496427498,-0.4912119581361516
7,-2.058899802821969,2.0607628464079917
8,-0.10641338441541626,0.035929568275064216
9,-0.517273684861199,-0.6184800988804992
10,-0.9934859021679552,1.0577312348984502
13,-1.2061097548360489,-0.7402582563022937
6,1.443385383041667,1.6974039491263593
11,0.5923834706792905,-0.6693757541250825
12,0.8657741917554445,-0.6876271057571398
14,0.78768021182158,-0.38607117005262315
This absolutely bizarre to me. I read in the man page that -n
is supposed to be numerical sort. Why would id
be placed in-between numbers? How is it that 10
is larger than 9
, but smaller than 6
, all the while 11
being greater than them all?
The -g
seems to work as I want (and as I think is natural), but this -n
option totally escapes me. What's this about? I think it can be related to locale, but once I specify the delimiter as being ,
, I don't think that would explain it.
sort
sort
asked Apr 15 at 14:37
user347221user347221
573 bronze badges
573 bronze badges
add a comment
|
add a comment
|
1 Answer
1
active
oldest
votes
TL;DR
Use sort -nk1,1 -t,
or otherwise with -k1
you're sorting on the full line where ,
is discarded in numbers as it's interpreted as a thousand separator.
Details
In English language locales, ,
is the thousand separator, which sort
ignores in the integer part of numbers.
In other words, in an English language locale, or any locale where ,
is a thousand separator (see the output of locale thousands_sep
), when sort -n
sees 11,000,000
it doesn't see the 11
number followed by some ignored garbage, but the 11000000
number. Similarly 11,0
is not 11
but 110
.
Now (and that's something many people trip on), -k1
defines a key that starts with the first field, but as you didn't specify where it stops, ends at the end of the line, so the sort key is the full line, which is the default.
So sort -nk1 -t,
is exactly the same as sort -n
.
With ,
ignored as a thousand separator, on your input sort
is actually sorting these numbers:
0
1
2
3
4
5
61.4433853830416671
7
8
9
10
110.5923834706792905
120.8657741917554445
13
140.78768021182158
So it's not 6
vs 10
vs 11
, but 61.4433853830416671
vs 10
vs 110.5923834706792905
.
Here, you want:
sort -nk1,1 -t,
To sort on the first ,
-delimited field only. -k1,1
defines a sort key that starts at the start of the first field and ends at the end of the first field.
You can also use sort -n
in the C locale where ,
is neither the decimal radix nor the thousand separator (and .
is the decimal radix):
LC_ALL=C sort -n
sort -g
works differently because sort
then uses strtold()
to interpret the key as a number and strtold()
doesn't recognise thousands separators.
As far as the id
header line is concerned, in a numeric comparison, that id...
is interpreted as 0
as there's no number to be seen there. It sorts after the line that starts with 0
because when two records sort the same (here with -n
in a numeric comparison) sort
does a last resort comparison which is a lexical comparison of the full line (and 0
sorts before i
).
With some sort
implementations, that last resort comparison can be disabled with -s
. Here LC_ALL=C sort -sn
would put the id
line first, but that's only because there are no negative keys in the input (id
(which again numerically is 0) would still sort after -1
). If you want to exclude the first line from the sorting, you can do:
(head -n1; LC_ALL=C sort -n) < file
Thanks.sort -t, -n -k1,1
is not working for me, it's placing0
aboveid
. Also, does your answer explain why10
is larger than9
, but smaller than6
, all the while11
being greater than them all? It's genuine question, I'm not able to answer this myself from reading your answer.
– user347221
Apr 15 at 16:18
@user347221, see if the edit makes it any clearer.
– Stéphane Chazelas
Apr 15 at 16:34
Why do you talk so much about the thousands separator? There's nothing in the question that suggests that they expected it to be part of the number. They have-t","
to use it as the field delimiter.
– Barmar
Apr 15 at 16:57
Where is61.4433853830416671
in the input file? I see6,1.443385383041667,1.6974039491263593
.
– Barmar
Apr 15 at 16:59
1
@StéphaneChazelas Thank you, this is great. unix.SE is eons beyond other SE sites. People actually help here. I've had great experiences with many of the users here. Gilles, Kusalananda, Stephen, terdon to name a few. Thank you all.
– user347221
Apr 15 at 17:22
|
show 4 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f512596%2fsorting-numerically%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
TL;DR
Use sort -nk1,1 -t,
or otherwise with -k1
you're sorting on the full line where ,
is discarded in numbers as it's interpreted as a thousand separator.
Details
In English language locales, ,
is the thousand separator, which sort
ignores in the integer part of numbers.
In other words, in an English language locale, or any locale where ,
is a thousand separator (see the output of locale thousands_sep
), when sort -n
sees 11,000,000
it doesn't see the 11
number followed by some ignored garbage, but the 11000000
number. Similarly 11,0
is not 11
but 110
.
Now (and that's something many people trip on), -k1
defines a key that starts with the first field, but as you didn't specify where it stops, ends at the end of the line, so the sort key is the full line, which is the default.
So sort -nk1 -t,
is exactly the same as sort -n
.
With ,
ignored as a thousand separator, on your input sort
is actually sorting these numbers:
0
1
2
3
4
5
61.4433853830416671
7
8
9
10
110.5923834706792905
120.8657741917554445
13
140.78768021182158
So it's not 6
vs 10
vs 11
, but 61.4433853830416671
vs 10
vs 110.5923834706792905
.
Here, you want:
sort -nk1,1 -t,
To sort on the first ,
-delimited field only. -k1,1
defines a sort key that starts at the start of the first field and ends at the end of the first field.
You can also use sort -n
in the C locale where ,
is neither the decimal radix nor the thousand separator (and .
is the decimal radix):
LC_ALL=C sort -n
sort -g
works differently because sort
then uses strtold()
to interpret the key as a number and strtold()
doesn't recognise thousands separators.
As far as the id
header line is concerned, in a numeric comparison, that id...
is interpreted as 0
as there's no number to be seen there. It sorts after the line that starts with 0
because when two records sort the same (here with -n
in a numeric comparison) sort
does a last resort comparison which is a lexical comparison of the full line (and 0
sorts before i
).
With some sort
implementations, that last resort comparison can be disabled with -s
. Here LC_ALL=C sort -sn
would put the id
line first, but that's only because there are no negative keys in the input (id
(which again numerically is 0) would still sort after -1
). If you want to exclude the first line from the sorting, you can do:
(head -n1; LC_ALL=C sort -n) < file
Thanks.sort -t, -n -k1,1
is not working for me, it's placing0
aboveid
. Also, does your answer explain why10
is larger than9
, but smaller than6
, all the while11
being greater than them all? It's genuine question, I'm not able to answer this myself from reading your answer.
– user347221
Apr 15 at 16:18
@user347221, see if the edit makes it any clearer.
– Stéphane Chazelas
Apr 15 at 16:34
Why do you talk so much about the thousands separator? There's nothing in the question that suggests that they expected it to be part of the number. They have-t","
to use it as the field delimiter.
– Barmar
Apr 15 at 16:57
Where is61.4433853830416671
in the input file? I see6,1.443385383041667,1.6974039491263593
.
– Barmar
Apr 15 at 16:59
1
@StéphaneChazelas Thank you, this is great. unix.SE is eons beyond other SE sites. People actually help here. I've had great experiences with many of the users here. Gilles, Kusalananda, Stephen, terdon to name a few. Thank you all.
– user347221
Apr 15 at 17:22
|
show 4 more comments
TL;DR
Use sort -nk1,1 -t,
or otherwise with -k1
you're sorting on the full line where ,
is discarded in numbers as it's interpreted as a thousand separator.
Details
In English language locales, ,
is the thousand separator, which sort
ignores in the integer part of numbers.
In other words, in an English language locale, or any locale where ,
is a thousand separator (see the output of locale thousands_sep
), when sort -n
sees 11,000,000
it doesn't see the 11
number followed by some ignored garbage, but the 11000000
number. Similarly 11,0
is not 11
but 110
.
Now (and that's something many people trip on), -k1
defines a key that starts with the first field, but as you didn't specify where it stops, ends at the end of the line, so the sort key is the full line, which is the default.
So sort -nk1 -t,
is exactly the same as sort -n
.
With ,
ignored as a thousand separator, on your input sort
is actually sorting these numbers:
0
1
2
3
4
5
61.4433853830416671
7
8
9
10
110.5923834706792905
120.8657741917554445
13
140.78768021182158
So it's not 6
vs 10
vs 11
, but 61.4433853830416671
vs 10
vs 110.5923834706792905
.
Here, you want:
sort -nk1,1 -t,
To sort on the first ,
-delimited field only. -k1,1
defines a sort key that starts at the start of the first field and ends at the end of the first field.
You can also use sort -n
in the C locale where ,
is neither the decimal radix nor the thousand separator (and .
is the decimal radix):
LC_ALL=C sort -n
sort -g
works differently because sort
then uses strtold()
to interpret the key as a number and strtold()
doesn't recognise thousands separators.
As far as the id
header line is concerned, in a numeric comparison, that id...
is interpreted as 0
as there's no number to be seen there. It sorts after the line that starts with 0
because when two records sort the same (here with -n
in a numeric comparison) sort
does a last resort comparison which is a lexical comparison of the full line (and 0
sorts before i
).
With some sort
implementations, that last resort comparison can be disabled with -s
. Here LC_ALL=C sort -sn
would put the id
line first, but that's only because there are no negative keys in the input (id
(which again numerically is 0) would still sort after -1
). If you want to exclude the first line from the sorting, you can do:
(head -n1; LC_ALL=C sort -n) < file
Thanks.sort -t, -n -k1,1
is not working for me, it's placing0
aboveid
. Also, does your answer explain why10
is larger than9
, but smaller than6
, all the while11
being greater than them all? It's genuine question, I'm not able to answer this myself from reading your answer.
– user347221
Apr 15 at 16:18
@user347221, see if the edit makes it any clearer.
– Stéphane Chazelas
Apr 15 at 16:34
Why do you talk so much about the thousands separator? There's nothing in the question that suggests that they expected it to be part of the number. They have-t","
to use it as the field delimiter.
– Barmar
Apr 15 at 16:57
Where is61.4433853830416671
in the input file? I see6,1.443385383041667,1.6974039491263593
.
– Barmar
Apr 15 at 16:59
1
@StéphaneChazelas Thank you, this is great. unix.SE is eons beyond other SE sites. People actually help here. I've had great experiences with many of the users here. Gilles, Kusalananda, Stephen, terdon to name a few. Thank you all.
– user347221
Apr 15 at 17:22
|
show 4 more comments
TL;DR
Use sort -nk1,1 -t,
or otherwise with -k1
you're sorting on the full line where ,
is discarded in numbers as it's interpreted as a thousand separator.
Details
In English language locales, ,
is the thousand separator, which sort
ignores in the integer part of numbers.
In other words, in an English language locale, or any locale where ,
is a thousand separator (see the output of locale thousands_sep
), when sort -n
sees 11,000,000
it doesn't see the 11
number followed by some ignored garbage, but the 11000000
number. Similarly 11,0
is not 11
but 110
.
Now (and that's something many people trip on), -k1
defines a key that starts with the first field, but as you didn't specify where it stops, ends at the end of the line, so the sort key is the full line, which is the default.
So sort -nk1 -t,
is exactly the same as sort -n
.
With ,
ignored as a thousand separator, on your input sort
is actually sorting these numbers:
0
1
2
3
4
5
61.4433853830416671
7
8
9
10
110.5923834706792905
120.8657741917554445
13
140.78768021182158
So it's not 6
vs 10
vs 11
, but 61.4433853830416671
vs 10
vs 110.5923834706792905
.
Here, you want:
sort -nk1,1 -t,
To sort on the first ,
-delimited field only. -k1,1
defines a sort key that starts at the start of the first field and ends at the end of the first field.
You can also use sort -n
in the C locale where ,
is neither the decimal radix nor the thousand separator (and .
is the decimal radix):
LC_ALL=C sort -n
sort -g
works differently because sort
then uses strtold()
to interpret the key as a number and strtold()
doesn't recognise thousands separators.
As far as the id
header line is concerned, in a numeric comparison, that id...
is interpreted as 0
as there's no number to be seen there. It sorts after the line that starts with 0
because when two records sort the same (here with -n
in a numeric comparison) sort
does a last resort comparison which is a lexical comparison of the full line (and 0
sorts before i
).
With some sort
implementations, that last resort comparison can be disabled with -s
. Here LC_ALL=C sort -sn
would put the id
line first, but that's only because there are no negative keys in the input (id
(which again numerically is 0) would still sort after -1
). If you want to exclude the first line from the sorting, you can do:
(head -n1; LC_ALL=C sort -n) < file
TL;DR
Use sort -nk1,1 -t,
or otherwise with -k1
you're sorting on the full line where ,
is discarded in numbers as it's interpreted as a thousand separator.
Details
In English language locales, ,
is the thousand separator, which sort
ignores in the integer part of numbers.
In other words, in an English language locale, or any locale where ,
is a thousand separator (see the output of locale thousands_sep
), when sort -n
sees 11,000,000
it doesn't see the 11
number followed by some ignored garbage, but the 11000000
number. Similarly 11,0
is not 11
but 110
.
Now (and that's something many people trip on), -k1
defines a key that starts with the first field, but as you didn't specify where it stops, ends at the end of the line, so the sort key is the full line, which is the default.
So sort -nk1 -t,
is exactly the same as sort -n
.
With ,
ignored as a thousand separator, on your input sort
is actually sorting these numbers:
0
1
2
3
4
5
61.4433853830416671
7
8
9
10
110.5923834706792905
120.8657741917554445
13
140.78768021182158
So it's not 6
vs 10
vs 11
, but 61.4433853830416671
vs 10
vs 110.5923834706792905
.
Here, you want:
sort -nk1,1 -t,
To sort on the first ,
-delimited field only. -k1,1
defines a sort key that starts at the start of the first field and ends at the end of the first field.
You can also use sort -n
in the C locale where ,
is neither the decimal radix nor the thousand separator (and .
is the decimal radix):
LC_ALL=C sort -n
sort -g
works differently because sort
then uses strtold()
to interpret the key as a number and strtold()
doesn't recognise thousands separators.
As far as the id
header line is concerned, in a numeric comparison, that id...
is interpreted as 0
as there's no number to be seen there. It sorts after the line that starts with 0
because when two records sort the same (here with -n
in a numeric comparison) sort
does a last resort comparison which is a lexical comparison of the full line (and 0
sorts before i
).
With some sort
implementations, that last resort comparison can be disabled with -s
. Here LC_ALL=C sort -sn
would put the id
line first, but that's only because there are no negative keys in the input (id
(which again numerically is 0) would still sort after -1
). If you want to exclude the first line from the sorting, you can do:
(head -n1; LC_ALL=C sort -n) < file
edited Apr 15 at 19:34
answered Apr 15 at 14:47
Stéphane ChazelasStéphane Chazelas
335k58 gold badges654 silver badges1030 bronze badges
335k58 gold badges654 silver badges1030 bronze badges
Thanks.sort -t, -n -k1,1
is not working for me, it's placing0
aboveid
. Also, does your answer explain why10
is larger than9
, but smaller than6
, all the while11
being greater than them all? It's genuine question, I'm not able to answer this myself from reading your answer.
– user347221
Apr 15 at 16:18
@user347221, see if the edit makes it any clearer.
– Stéphane Chazelas
Apr 15 at 16:34
Why do you talk so much about the thousands separator? There's nothing in the question that suggests that they expected it to be part of the number. They have-t","
to use it as the field delimiter.
– Barmar
Apr 15 at 16:57
Where is61.4433853830416671
in the input file? I see6,1.443385383041667,1.6974039491263593
.
– Barmar
Apr 15 at 16:59
1
@StéphaneChazelas Thank you, this is great. unix.SE is eons beyond other SE sites. People actually help here. I've had great experiences with many of the users here. Gilles, Kusalananda, Stephen, terdon to name a few. Thank you all.
– user347221
Apr 15 at 17:22
|
show 4 more comments
Thanks.sort -t, -n -k1,1
is not working for me, it's placing0
aboveid
. Also, does your answer explain why10
is larger than9
, but smaller than6
, all the while11
being greater than them all? It's genuine question, I'm not able to answer this myself from reading your answer.
– user347221
Apr 15 at 16:18
@user347221, see if the edit makes it any clearer.
– Stéphane Chazelas
Apr 15 at 16:34
Why do you talk so much about the thousands separator? There's nothing in the question that suggests that they expected it to be part of the number. They have-t","
to use it as the field delimiter.
– Barmar
Apr 15 at 16:57
Where is61.4433853830416671
in the input file? I see6,1.443385383041667,1.6974039491263593
.
– Barmar
Apr 15 at 16:59
1
@StéphaneChazelas Thank you, this is great. unix.SE is eons beyond other SE sites. People actually help here. I've had great experiences with many of the users here. Gilles, Kusalananda, Stephen, terdon to name a few. Thank you all.
– user347221
Apr 15 at 17:22
Thanks.
sort -t, -n -k1,1
is not working for me, it's placing 0
above id
. Also, does your answer explain why 10
is larger than 9
, but smaller than 6
, all the while 11
being greater than them all? It's genuine question, I'm not able to answer this myself from reading your answer.– user347221
Apr 15 at 16:18
Thanks.
sort -t, -n -k1,1
is not working for me, it's placing 0
above id
. Also, does your answer explain why 10
is larger than 9
, but smaller than 6
, all the while 11
being greater than them all? It's genuine question, I'm not able to answer this myself from reading your answer.– user347221
Apr 15 at 16:18
@user347221, see if the edit makes it any clearer.
– Stéphane Chazelas
Apr 15 at 16:34
@user347221, see if the edit makes it any clearer.
– Stéphane Chazelas
Apr 15 at 16:34
Why do you talk so much about the thousands separator? There's nothing in the question that suggests that they expected it to be part of the number. They have
-t","
to use it as the field delimiter.– Barmar
Apr 15 at 16:57
Why do you talk so much about the thousands separator? There's nothing in the question that suggests that they expected it to be part of the number. They have
-t","
to use it as the field delimiter.– Barmar
Apr 15 at 16:57
Where is
61.4433853830416671
in the input file? I see 6,1.443385383041667,1.6974039491263593
.– Barmar
Apr 15 at 16:59
Where is
61.4433853830416671
in the input file? I see 6,1.443385383041667,1.6974039491263593
.– Barmar
Apr 15 at 16:59
1
1
@StéphaneChazelas Thank you, this is great. unix.SE is eons beyond other SE sites. People actually help here. I've had great experiences with many of the users here. Gilles, Kusalananda, Stephen, terdon to name a few. Thank you all.
– user347221
Apr 15 at 17:22
@StéphaneChazelas Thank you, this is great. unix.SE is eons beyond other SE sites. People actually help here. I've had great experiences with many of the users here. Gilles, Kusalananda, Stephen, terdon to name a few. Thank you all.
– user347221
Apr 15 at 17:22
|
show 4 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f512596%2fsorting-numerically%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown