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;








7















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.










share|improve this question






























    7















    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.










    share|improve this question


























      7












      7








      7


      3






      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.










      share|improve this question














      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Apr 15 at 14:37









      user347221user347221

      573 bronze badges




      573 bronze badges























          1 Answer
          1






          active

          oldest

          votes


















          18
















          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





          share|improve this answer



























          • 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











          • 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






          • 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













          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
          );



          );














          draft saved

          draft discarded
















          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









          18
















          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





          share|improve this answer



























          • 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











          • 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






          • 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















          18
















          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





          share|improve this answer



























          • 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











          • 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






          • 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













          18














          18










          18









          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





          share|improve this answer















          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






          share|improve this answer














          share|improve this answer



          share|improve this answer








          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 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











          • 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






          • 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











          • @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 is 61.4433853830416671 in the input file? I see 6,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


















          draft saved

          draft discarded















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          Tamil (spriik) Luke uk diar | Nawigatjuun

          Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

          Where does the image of a data connector as a sharp metal spike originate from?Where does the concept of infected people turning into zombies only after death originate from?Where does the motif of a reanimated human head originate?Where did the notion that Dragons could speak originate?Where does the archetypal image of the 'Grey' alien come from?Where did the suffix '-Man' originate?Where does the notion of being injured or killed by an illusion originate?Where did the term “sophont” originate?Where does the trope of magic spells being driven by advanced technology originate from?Where did the term “the living impaired” originate?