Sort not sorting lines with a pipe '|' in it correctly












17















I am trying to sort some simple pipe-delimited data. However, sort isn't actually sorting. It moves my header row to the bottom, but my two rows starting with 241 are being split by a row starting with 24.



cat sort_fail.csv

column_a|column_b|column_c

241|212|20810378

24|121|2810172

241|213|20810376



sort sort_fail.csv

241|212|20810378

24|121|2810172

241|213|20810376

column_a|column_b|column_c


The column headers are being moved to the bottom of the file, so sort is clearly processing it. But, the actual values aren't being sorted like I'd expect.



In this case I worked around it with 



sort sort_fail.csv --field-separator='|' -k1,1


But, I feel like that shouldn't be necessary. Why is sort not sorting?






sort







share|improve this question




















  • 2





    use LC_COLLATE=C sort. Depending on what you're expecting, you may also need LC_COLLATE=C sort -t'|' -n

    – mosvy
    Dec 11 '18 at 22:49








  • 3





    To sort "csv style" data you may want to use csvsort from csvkit, which properly handles quoted values.

    – Bakuriu
    Dec 12 '18 at 8:17
















17















I am trying to sort some simple pipe-delimited data. However, sort isn't actually sorting. It moves my header row to the bottom, but my two rows starting with 241 are being split by a row starting with 24.



cat sort_fail.csv

column_a|column_b|column_c

241|212|20810378

24|121|2810172

241|213|20810376



sort sort_fail.csv

241|212|20810378

24|121|2810172

241|213|20810376

column_a|column_b|column_c


The column headers are being moved to the bottom of the file, so sort is clearly processing it. But, the actual values aren't being sorted like I'd expect.



In this case I worked around it with 



sort sort_fail.csv --field-separator='|' -k1,1


But, I feel like that shouldn't be necessary. Why is sort not sorting?






sort







share|improve this question




















  • 2





    use LC_COLLATE=C sort. Depending on what you're expecting, you may also need LC_COLLATE=C sort -t'|' -n

    – mosvy
    Dec 11 '18 at 22:49








  • 3





    To sort "csv style" data you may want to use csvsort from csvkit, which properly handles quoted values.

    – Bakuriu
    Dec 12 '18 at 8:17














17












17








17


5






I am trying to sort some simple pipe-delimited data. However, sort isn't actually sorting. It moves my header row to the bottom, but my two rows starting with 241 are being split by a row starting with 24.



cat sort_fail.csv

column_a|column_b|column_c

241|212|20810378

24|121|2810172

241|213|20810376



sort sort_fail.csv

241|212|20810378

24|121|2810172

241|213|20810376

column_a|column_b|column_c


The column headers are being moved to the bottom of the file, so sort is clearly processing it. But, the actual values aren't being sorted like I'd expect.



In this case I worked around it with 



sort sort_fail.csv --field-separator='|' -k1,1


But, I feel like that shouldn't be necessary. Why is sort not sorting?






sort







share|improve this question
















I am trying to sort some simple pipe-delimited data. However, sort isn't actually sorting. It moves my header row to the bottom, but my two rows starting with 241 are being split by a row starting with 24.



cat sort_fail.csv

column_a|column_b|column_c

241|212|20810378

24|121|2810172

241|213|20810376



sort sort_fail.csv

241|212|20810378

24|121|2810172

241|213|20810376

column_a|column_b|column_c


The column headers are being moved to the bottom of the file, so sort is clearly processing it. But, the actual values aren't being sorted like I'd expect.



In this case I worked around it with 



sort sort_fail.csv --field-separator='|' -k1,1


But, I feel like that shouldn't be necessary. Why is sort not sorting?






sort




sort






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 12 '18 at 3:32









muru

36.7k589163




36.7k589163










asked Dec 11 '18 at 22:43









user10777668user10777668

885




885








  • 2





    use LC_COLLATE=C sort. Depending on what you're expecting, you may also need LC_COLLATE=C sort -t'|' -n

    – mosvy
    Dec 11 '18 at 22:49








  • 3





    To sort "csv style" data you may want to use csvsort from csvkit, which properly handles quoted values.

    – Bakuriu
    Dec 12 '18 at 8:17














  • 2





    use LC_COLLATE=C sort. Depending on what you're expecting, you may also need LC_COLLATE=C sort -t'|' -n

    – mosvy
    Dec 11 '18 at 22:49








  • 3





    To sort "csv style" data you may want to use csvsort from csvkit, which properly handles quoted values.

    – Bakuriu
    Dec 12 '18 at 8:17








2




2





use LC_COLLATE=C sort. Depending on what you're expecting, you may also need LC_COLLATE=C sort -t'|' -n

– mosvy
Dec 11 '18 at 22:49







use LC_COLLATE=C sort. Depending on what you're expecting, you may also need LC_COLLATE=C sort -t'|' -n

– mosvy
Dec 11 '18 at 22:49






3




3





To sort "csv style" data you may want to use csvsort from csvkit, which properly handles quoted values.

– Bakuriu
Dec 12 '18 at 8:17





To sort "csv style" data you may want to use csvsort from csvkit, which properly handles quoted values.

– Bakuriu
Dec 12 '18 at 8:17










3 Answers
3






active

oldest

votes


















32














sort is locale aware, so depending on your LC_COLLATE setting (which is inherited from LANG) you may get different results:



$ LANG=C sort sort_fail.csv 

241|212|20810378

241|213|20810376

24|121|2810172

column_a|column_b|column_c



$ LANG=en_US sort sort_fail.csv

241|212|20810378

24|121|2810172

241|213|20810376

column_a|column_b|column_c


This can cause problems in scripts, because you may not be aware of what the calling locale is set to, and so may get different results.



It's not uncommon for scripts to force the setting needed



e.g.



$ grep 'LC.*sort' /bin/precat

      LC_COLLATE=C sort -u | prezip-bin -z "$cmd: $2"


Now what's interesting, here, is the | character looks odd.



But that's because the default rule for en_US, which derives from ISO, says



$ grep 007C /usr/share/i18n/locales/iso14651_t1_common

<U007C> IGNORE;IGNORE;IGNORE;<j> # 142 |


Which means the | character is ignored and the sort order would be as if the character doesn't exist..



$ tr -d '|' < sort_fail.csv | LANG=C sort

24121220810378

241212810172

24121320810376

column_acolumn_bcolumn_c


And that matches the "unexpected" sorting you are seeing.



The work arounds are to use -n (to force numeric sorts), or to use the field separator (as you did) or to use the C locale.






share|improve this answer


























  • Fascinating. I did see some other hits about localization, but figured that would impact the relative ordering of 24 vs 241, not something like this.

    – user10777668
    Dec 12 '18 at 0:24






  • 7





    something extra useful in GNU sort is the --debug option, which indicates the key (underlined) used to compare

    – Jeff Schaller♦
    Dec 12 '18 at 3:36











  • running with --debug just underlines the entire line - sort is including the pipe character, it's just set to have no impact because of localization. It's a good feature but didn't help me in this case (I tried :)

    – user10777668
    Dec 12 '18 at 17:37











  • That's exactly why I mentioned it, @user10777668 -- it indicates that sort is using the entire line instead of stopping at characters that we assume it is.

    – Jeff Schaller♦
    Dec 12 '18 at 18:03











  • I wasn't expecting it to stop. I was expecting it to recognize the pipe character and include that in the sort, therefore treating 24|1 and 241 differently. I'm not sure how --debug would have changed that, and in fact given that it underlines the | seems like it would have actively distracted from the real problem where localization led to the pipe character being ingored

    – user10777668
    Dec 12 '18 at 18:30



















1














What irritates me is that the 24 doesn't move from its place between the two 241. The second field starts with a 1. Trying the sort with a leading 4 in the second field, the 24 is moved down, so I suspect sort just ignores the | unless told otherwise.
Try sort -n...






share|improve this answer































    0














    -n, --numeric-sort
    compare according to string numerical value



    210
    
23


    Without the -n, 210 by text is ahead of 23 as it goes character my character.






    share|improve this answer
























    • You're right, but this doesn't explain the pipe char being different. The other answers show that because of the locale, the pipe is treated as not there so the next digit is what decides the ordering.

      – Criggie
      Dec 12 '18 at 6:59












    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/3.0/"u003ecc by-sa 3.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%2f487458%2fsort-not-sorting-lines-with-a-pipe-in-it-correctly%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    32














    sort is locale aware, so depending on your LC_COLLATE setting (which is inherited from LANG) you may get different results:



    $ LANG=C sort sort_fail.csv 
    
241|212|20810378
    
241|213|20810376
    
24|121|2810172
    
column_a|column_b|column_c
    

    
$ LANG=en_US sort sort_fail.csv
    
241|212|20810378
    
24|121|2810172
    
241|213|20810376
    
column_a|column_b|column_c


    This can cause problems in scripts, because you may not be aware of what the calling locale is set to, and so may get different results.



    It's not uncommon for scripts to force the setting needed



    e.g.



    $ grep 'LC.*sort' /bin/precat
    
      LC_COLLATE=C sort -u | prezip-bin -z "$cmd: $2"


    Now what's interesting, here, is the | character looks odd.



    But that's because the default rule for en_US, which derives from ISO, says



    $ grep 007C /usr/share/i18n/locales/iso14651_t1_common
    
<U007C> IGNORE;IGNORE;IGNORE;<j> # 142 |


    Which means the | character is ignored and the sort order would be as if the character doesn't exist..



    $ tr -d '|' < sort_fail.csv | LANG=C sort
    
24121220810378
    
241212810172
    
24121320810376
    
column_acolumn_bcolumn_c


    And that matches the "unexpected" sorting you are seeing.



    The work arounds are to use -n (to force numeric sorts), or to use the field separator (as you did) or to use the C locale.






    share|improve this answer


























    • Fascinating. I did see some other hits about localization, but figured that would impact the relative ordering of 24 vs 241, not something like this.

      – user10777668
      Dec 12 '18 at 0:24






    • 7





      something extra useful in GNU sort is the --debug option, which indicates the key (underlined) used to compare

      – Jeff Schaller♦
      Dec 12 '18 at 3:36











    • running with --debug just underlines the entire line - sort is including the pipe character, it's just set to have no impact because of localization. It's a good feature but didn't help me in this case (I tried :)

      – user10777668
      Dec 12 '18 at 17:37











    • That's exactly why I mentioned it, @user10777668 -- it indicates that sort is using the entire line instead of stopping at characters that we assume it is.

      – Jeff Schaller♦
      Dec 12 '18 at 18:03











    • I wasn't expecting it to stop. I was expecting it to recognize the pipe character and include that in the sort, therefore treating 24|1 and 241 differently. I'm not sure how --debug would have changed that, and in fact given that it underlines the | seems like it would have actively distracted from the real problem where localization led to the pipe character being ingored

      – user10777668
      Dec 12 '18 at 18:30
















    32














    sort is locale aware, so depending on your LC_COLLATE setting (which is inherited from LANG) you may get different results:



    $ LANG=C sort sort_fail.csv 
    
241|212|20810378
    
241|213|20810376
    
24|121|2810172
    
column_a|column_b|column_c
    

    
$ LANG=en_US sort sort_fail.csv
    
241|212|20810378
    
24|121|2810172
    
241|213|20810376
    
column_a|column_b|column_c


    This can cause problems in scripts, because you may not be aware of what the calling locale is set to, and so may get different results.



    It's not uncommon for scripts to force the setting needed



    e.g.



    $ grep 'LC.*sort' /bin/precat
    
      LC_COLLATE=C sort -u | prezip-bin -z "$cmd: $2"


    Now what's interesting, here, is the | character looks odd.



    But that's because the default rule for en_US, which derives from ISO, says



    $ grep 007C /usr/share/i18n/locales/iso14651_t1_common
    
<U007C> IGNORE;IGNORE;IGNORE;<j> # 142 |


    Which means the | character is ignored and the sort order would be as if the character doesn't exist..



    $ tr -d '|' < sort_fail.csv | LANG=C sort
    
24121220810378
    
241212810172
    
24121320810376
    
column_acolumn_bcolumn_c


    And that matches the "unexpected" sorting you are seeing.



    The work arounds are to use -n (to force numeric sorts), or to use the field separator (as you did) or to use the C locale.






    share|improve this answer


























    • Fascinating. I did see some other hits about localization, but figured that would impact the relative ordering of 24 vs 241, not something like this.

      – user10777668
      Dec 12 '18 at 0:24






    • 7





      something extra useful in GNU sort is the --debug option, which indicates the key (underlined) used to compare

      – Jeff Schaller♦
      Dec 12 '18 at 3:36











    • running with --debug just underlines the entire line - sort is including the pipe character, it's just set to have no impact because of localization. It's a good feature but didn't help me in this case (I tried :)

      – user10777668
      Dec 12 '18 at 17:37











    • That's exactly why I mentioned it, @user10777668 -- it indicates that sort is using the entire line instead of stopping at characters that we assume it is.

      – Jeff Schaller♦
      Dec 12 '18 at 18:03











    • I wasn't expecting it to stop. I was expecting it to recognize the pipe character and include that in the sort, therefore treating 24|1 and 241 differently. I'm not sure how --debug would have changed that, and in fact given that it underlines the | seems like it would have actively distracted from the real problem where localization led to the pipe character being ingored

      – user10777668
      Dec 12 '18 at 18:30














    32












    32








    32







    sort is locale aware, so depending on your LC_COLLATE setting (which is inherited from LANG) you may get different results:



    $ LANG=C sort sort_fail.csv 
    
241|212|20810378
    
241|213|20810376
    
24|121|2810172
    
column_a|column_b|column_c
    

    
$ LANG=en_US sort sort_fail.csv
    
241|212|20810378
    
24|121|2810172
    
241|213|20810376
    
column_a|column_b|column_c


    This can cause problems in scripts, because you may not be aware of what the calling locale is set to, and so may get different results.



    It's not uncommon for scripts to force the setting needed



    e.g.



    $ grep 'LC.*sort' /bin/precat
    
      LC_COLLATE=C sort -u | prezip-bin -z "$cmd: $2"


    Now what's interesting, here, is the | character looks odd.



    But that's because the default rule for en_US, which derives from ISO, says



    $ grep 007C /usr/share/i18n/locales/iso14651_t1_common
    
<U007C> IGNORE;IGNORE;IGNORE;<j> # 142 |


    Which means the | character is ignored and the sort order would be as if the character doesn't exist..



    $ tr -d '|' < sort_fail.csv | LANG=C sort
    
24121220810378
    
241212810172
    
24121320810376
    
column_acolumn_bcolumn_c


    And that matches the "unexpected" sorting you are seeing.



    The work arounds are to use -n (to force numeric sorts), or to use the field separator (as you did) or to use the C locale.






    share|improve this answer















    sort is locale aware, so depending on your LC_COLLATE setting (which is inherited from LANG) you may get different results:



    $ LANG=C sort sort_fail.csv 
    
241|212|20810378
    
241|213|20810376
    
24|121|2810172
    
column_a|column_b|column_c
    

    
$ LANG=en_US sort sort_fail.csv
    
241|212|20810378
    
24|121|2810172
    
241|213|20810376
    
column_a|column_b|column_c


    This can cause problems in scripts, because you may not be aware of what the calling locale is set to, and so may get different results.



    It's not uncommon for scripts to force the setting needed



    e.g.



    $ grep 'LC.*sort' /bin/precat
    
      LC_COLLATE=C sort -u | prezip-bin -z "$cmd: $2"


    Now what's interesting, here, is the | character looks odd.



    But that's because the default rule for en_US, which derives from ISO, says



    $ grep 007C /usr/share/i18n/locales/iso14651_t1_common
    
<U007C> IGNORE;IGNORE;IGNORE;<j> # 142 |


    Which means the | character is ignored and the sort order would be as if the character doesn't exist..



    $ tr -d '|' < sort_fail.csv | LANG=C sort
    
24121220810378
    
241212810172
    
24121320810376
    
column_acolumn_bcolumn_c


    And that matches the "unexpected" sorting you are seeing.



    The work arounds are to use -n (to force numeric sorts), or to use the field separator (as you did) or to use the C locale.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 12 '18 at 11:55









    kasperd

    2,66011129




    2,66011129










    answered Dec 12 '18 at 0:04









    Stephen HarrisStephen Harris

    27.2k35283




    27.2k35283













    • Fascinating. I did see some other hits about localization, but figured that would impact the relative ordering of 24 vs 241, not something like this.

      – user10777668
      Dec 12 '18 at 0:24






    • 7





      something extra useful in GNU sort is the --debug option, which indicates the key (underlined) used to compare

      – Jeff Schaller♦
      Dec 12 '18 at 3:36











    • running with --debug just underlines the entire line - sort is including the pipe character, it's just set to have no impact because of localization. It's a good feature but didn't help me in this case (I tried :)

      – user10777668
      Dec 12 '18 at 17:37











    • That's exactly why I mentioned it, @user10777668 -- it indicates that sort is using the entire line instead of stopping at characters that we assume it is.

      – Jeff Schaller♦
      Dec 12 '18 at 18:03











    • I wasn't expecting it to stop. I was expecting it to recognize the pipe character and include that in the sort, therefore treating 24|1 and 241 differently. I'm not sure how --debug would have changed that, and in fact given that it underlines the | seems like it would have actively distracted from the real problem where localization led to the pipe character being ingored

      – user10777668
      Dec 12 '18 at 18:30



















    • Fascinating. I did see some other hits about localization, but figured that would impact the relative ordering of 24 vs 241, not something like this.

      – user10777668
      Dec 12 '18 at 0:24






    • 7





      something extra useful in GNU sort is the --debug option, which indicates the key (underlined) used to compare

      – Jeff Schaller♦
      Dec 12 '18 at 3:36











    • running with --debug just underlines the entire line - sort is including the pipe character, it's just set to have no impact because of localization. It's a good feature but didn't help me in this case (I tried :)

      – user10777668
      Dec 12 '18 at 17:37











    • That's exactly why I mentioned it, @user10777668 -- it indicates that sort is using the entire line instead of stopping at characters that we assume it is.

      – Jeff Schaller♦
      Dec 12 '18 at 18:03











    • I wasn't expecting it to stop. I was expecting it to recognize the pipe character and include that in the sort, therefore treating 24|1 and 241 differently. I'm not sure how --debug would have changed that, and in fact given that it underlines the | seems like it would have actively distracted from the real problem where localization led to the pipe character being ingored

      – user10777668
      Dec 12 '18 at 18:30

















    Fascinating. I did see some other hits about localization, but figured that would impact the relative ordering of 24 vs 241, not something like this.

    – user10777668
    Dec 12 '18 at 0:24





    Fascinating. I did see some other hits about localization, but figured that would impact the relative ordering of 24 vs 241, not something like this.

    – user10777668
    Dec 12 '18 at 0:24




    7




    7





    something extra useful in GNU sort is the --debug option, which indicates the key (underlined) used to compare

    – Jeff Schaller♦
    Dec 12 '18 at 3:36





    something extra useful in GNU sort is the --debug option, which indicates the key (underlined) used to compare

    – Jeff Schaller♦
    Dec 12 '18 at 3:36













    running with --debug just underlines the entire line - sort is including the pipe character, it's just set to have no impact because of localization. It's a good feature but didn't help me in this case (I tried :)

    – user10777668
    Dec 12 '18 at 17:37





    running with --debug just underlines the entire line - sort is including the pipe character, it's just set to have no impact because of localization. It's a good feature but didn't help me in this case (I tried :)

    – user10777668
    Dec 12 '18 at 17:37













    That's exactly why I mentioned it, @user10777668 -- it indicates that sort is using the entire line instead of stopping at characters that we assume it is.

    – Jeff Schaller♦
    Dec 12 '18 at 18:03





    That's exactly why I mentioned it, @user10777668 -- it indicates that sort is using the entire line instead of stopping at characters that we assume it is.

    – Jeff Schaller♦
    Dec 12 '18 at 18:03













    I wasn't expecting it to stop. I was expecting it to recognize the pipe character and include that in the sort, therefore treating 24|1 and 241 differently. I'm not sure how --debug would have changed that, and in fact given that it underlines the | seems like it would have actively distracted from the real problem where localization led to the pipe character being ingored

    – user10777668
    Dec 12 '18 at 18:30





    I wasn't expecting it to stop. I was expecting it to recognize the pipe character and include that in the sort, therefore treating 24|1 and 241 differently. I'm not sure how --debug would have changed that, and in fact given that it underlines the | seems like it would have actively distracted from the real problem where localization led to the pipe character being ingored

    – user10777668
    Dec 12 '18 at 18:30













    1














    What irritates me is that the 24 doesn't move from its place between the two 241. The second field starts with a 1. Trying the sort with a leading 4 in the second field, the 24 is moved down, so I suspect sort just ignores the | unless told otherwise.
    Try sort -n...






    share|improve this answer




























      1














      What irritates me is that the 24 doesn't move from its place between the two 241. The second field starts with a 1. Trying the sort with a leading 4 in the second field, the 24 is moved down, so I suspect sort just ignores the | unless told otherwise.
      Try sort -n...






      share|improve this answer


























        1












        1








        1







        What irritates me is that the 24 doesn't move from its place between the two 241. The second field starts with a 1. Trying the sort with a leading 4 in the second field, the 24 is moved down, so I suspect sort just ignores the | unless told otherwise.
        Try sort -n...






        share|improve this answer













        What irritates me is that the 24 doesn't move from its place between the two 241. The second field starts with a 1. Trying the sort with a leading 4 in the second field, the 24 is moved down, so I suspect sort just ignores the | unless told otherwise.
        Try sort -n...







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 11 '18 at 22:53









        RudiCRudiC

        4,3241312




        4,3241312























            0














            -n, --numeric-sort
            compare according to string numerical value



            210
            
23


            Without the -n, 210 by text is ahead of 23 as it goes character my character.






            share|improve this answer
























            • You're right, but this doesn't explain the pipe char being different. The other answers show that because of the locale, the pipe is treated as not there so the next digit is what decides the ordering.

              – Criggie
              Dec 12 '18 at 6:59
















            0














            -n, --numeric-sort
            compare according to string numerical value



            210
            
23


            Without the -n, 210 by text is ahead of 23 as it goes character my character.






            share|improve this answer
























            • You're right, but this doesn't explain the pipe char being different. The other answers show that because of the locale, the pipe is treated as not there so the next digit is what decides the ordering.

              – Criggie
              Dec 12 '18 at 6:59














            0












            0








            0







            -n, --numeric-sort
            compare according to string numerical value



            210
            
23


            Without the -n, 210 by text is ahead of 23 as it goes character my character.






            share|improve this answer













            -n, --numeric-sort
            compare according to string numerical value



            210
            
23


            Without the -n, 210 by text is ahead of 23 as it goes character my character.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Dec 12 '18 at 1:12









            michaelkriegermichaelkrieger

            161




            161













            • You're right, but this doesn't explain the pipe char being different. The other answers show that because of the locale, the pipe is treated as not there so the next digit is what decides the ordering.

              – Criggie
              Dec 12 '18 at 6:59



















            • You're right, but this doesn't explain the pipe char being different. The other answers show that because of the locale, the pipe is treated as not there so the next digit is what decides the ordering.

              – Criggie
              Dec 12 '18 at 6:59

















            You're right, but this doesn't explain the pipe char being different. The other answers show that because of the locale, the pipe is treated as not there so the next digit is what decides the ordering.

            – Criggie
            Dec 12 '18 at 6:59





            You're right, but this doesn't explain the pipe char being different. The other answers show that because of the locale, the pipe is treated as not there so the next digit is what decides the ordering.

            – Criggie
            Dec 12 '18 at 6:59


















            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%2f487458%2fsort-not-sorting-lines-with-a-pipe-in-it-correctly%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

            How to change which sound is reproduced for terminal bell?

            Image
            3 Recently upgrade to 18.10 from 18.04, and using the terminal is becoming annoying: the new alert sound is a drip ( /usr/share/sounds/gnome/default/alerts/drip.ogg ), and the previous one is still located at ( /usr/share/sounds/ubuntu/stereo/bell.ogg ). My issue is that at the gnome-terminal, when autocompleting or pressing left BOTH sounds are reproduced, at the same time. I want to just have ubuntu/stereo/bell.ogg active, not both . At the moment I have been only able to reduce the volume of the alerts (but still both are played), or turn the alerts down (but I dislike both "solutions"). gnome-terminal 18.10 teminal-bell share | improve this question ...
            Read more

            Can I use Tabulator js library in my java Spring + Thymeleaf project?

            Image
            0 I want to add Tabulator js to my java project. I added tabulator.min.js, tabulator.min.css to resources folder. After that added to my html page these dependencies as recommending in readme.md. <link rel="stylesheet" th:href="@{/css/tabulator.min.css}"> <script type="text/javascript" th:src="@{/js/tabulator.min.js}"></script> Now my tables view all elements, that I have in the html page, but not correct. In the documentation of Tabulator is example how to create header and table, var table = new Tabulator("#example-table", { columns:[ {title:"Name", field:"name", sorter:"string", width:200, editor:true}, {title:"Age", field:"age", sorter:"...
            Read more

            Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

            Image
            up vote 5 down vote favorite 2 I would like to make it so that the vertical space below the title of each chapter is the same when using the Bjornstrup package (i.e. so that the descenders do not affect the spacing - as shown by the red arrow in the picture below). I think I'm fairly happy with the spacing around "A chapter", so I'd really like titles without descenders (e.g. "Contents") to have the same vertical spacing as "A chapter" below the title. I would also like to remove the large "0" in the contents title. Any help appreciated, as always. documentclass[11pt,a4paper]{book} % Packages[![enter image description here][1]][1] usepackage[left=3.5cm, right=3.5cm, top=4.3cm, bottom=4.25cm]{geometry} usepackage[utf8]{inputenc} usepackage{libertine} usepackage[libertine]{newtx...
            Read more