Sort not sorting lines with a pipe '|' in it correctly
up vote
16
down vote
favorite
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
New contributor
user10777668 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
16
down vote
favorite
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
New contributor
user10777668 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
useLC_COLLATE=C sort. Depending on what you're expecting, you may also needLC_COLLATE=C sort -t'|' -n
– mosvy
Dec 11 at 22:49
3
To sort "csv style" data you may want to usecsvsortfromcsvkit, which properly handles quoted values.
– Bakuriu
Dec 12 at 8:17
add a comment |
up vote
16
down vote
favorite
up vote
16
down vote
favorite
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
New contributor
user10777668 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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
New contributor
user10777668 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user10777668 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited Dec 12 at 3:32
muru
35.5k582157
35.5k582157
New contributor
user10777668 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Dec 11 at 22:43
user10777668
834
834
New contributor
user10777668 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user10777668 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
user10777668 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
useLC_COLLATE=C sort. Depending on what you're expecting, you may also needLC_COLLATE=C sort -t'|' -n
– mosvy
Dec 11 at 22:49
3
To sort "csv style" data you may want to usecsvsortfromcsvkit, which properly handles quoted values.
– Bakuriu
Dec 12 at 8:17
add a comment |
2
useLC_COLLATE=C sort. Depending on what you're expecting, you may also needLC_COLLATE=C sort -t'|' -n
– mosvy
Dec 11 at 22:49
3
To sort "csv style" data you may want to usecsvsortfromcsvkit, which properly handles quoted values.
– Bakuriu
Dec 12 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 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 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 at 8:17
To sort "csv style" data you may want to use
csvsort from csvkit, which properly handles quoted values.– Bakuriu
Dec 12 at 8:17
add a comment |
3 Answers
3
active
oldest
votes
up vote
31
down vote
accepted
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.
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 at 0:24
5
something extra useful in GNU sort is the--debugoption, which indicates the key (underlined) used to compare
– Jeff Schaller
Dec 12 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 at 17:37
That's exactly why I mentioned it, @user10777668 -- it indicates thatsortis using the entire line instead of stopping at characters that we assume it is.
– Jeff Schaller
Dec 12 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 at 18:30
add a comment |
up vote
1
down vote
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...
add a comment |
up vote
0
down vote
-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.
New contributor
michaelkrieger is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 at 6:59
add a comment |
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',
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
});
}
});
user10777668 is a new contributor. Be nice, and check out our Code of Conduct.
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%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
up vote
31
down vote
accepted
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.
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 at 0:24
5
something extra useful in GNU sort is the--debugoption, which indicates the key (underlined) used to compare
– Jeff Schaller
Dec 12 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 at 17:37
That's exactly why I mentioned it, @user10777668 -- it indicates thatsortis using the entire line instead of stopping at characters that we assume it is.
– Jeff Schaller
Dec 12 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 at 18:30
add a comment |
up vote
31
down vote
accepted
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.
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 at 0:24
5
something extra useful in GNU sort is the--debugoption, which indicates the key (underlined) used to compare
– Jeff Schaller
Dec 12 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 at 17:37
That's exactly why I mentioned it, @user10777668 -- it indicates thatsortis using the entire line instead of stopping at characters that we assume it is.
– Jeff Schaller
Dec 12 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 at 18:30
add a comment |
up vote
31
down vote
accepted
up vote
31
down vote
accepted
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.
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.
edited Dec 12 at 11:55
kasperd
2,20911027
2,20911027
answered Dec 12 at 0:04
Stephen Harris
24.1k24477
24.1k24477
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 at 0:24
5
something extra useful in GNU sort is the--debugoption, which indicates the key (underlined) used to compare
– Jeff Schaller
Dec 12 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 at 17:37
That's exactly why I mentioned it, @user10777668 -- it indicates thatsortis using the entire line instead of stopping at characters that we assume it is.
– Jeff Schaller
Dec 12 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 at 18:30
add a comment |
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 at 0:24
5
something extra useful in GNU sort is the--debugoption, which indicates the key (underlined) used to compare
– Jeff Schaller
Dec 12 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 at 17:37
That's exactly why I mentioned it, @user10777668 -- it indicates thatsortis using the entire line instead of stopping at characters that we assume it is.
– Jeff Schaller
Dec 12 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 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 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 at 0:24
5
5
something extra useful in GNU sort is the
--debug option, which indicates the key (underlined) used to compare– Jeff Schaller
Dec 12 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 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 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 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 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 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 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 at 18:30
add a comment |
up vote
1
down vote
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...
add a comment |
up vote
1
down vote
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...
add a comment |
up vote
1
down vote
up vote
1
down vote
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...
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...
answered Dec 11 at 22:53
RudiC
3,9391312
3,9391312
add a comment |
add a comment |
up vote
0
down vote
-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.
New contributor
michaelkrieger is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 at 6:59
add a comment |
up vote
0
down vote
-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.
New contributor
michaelkrieger is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 at 6:59
add a comment |
up vote
0
down vote
up vote
0
down vote
-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.
New contributor
michaelkrieger is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
-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.
New contributor
michaelkrieger is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
michaelkrieger is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered Dec 12 at 1:12
michaelkrieger
161
161
New contributor
michaelkrieger is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
michaelkrieger is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
michaelkrieger is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 at 6:59
add a comment |
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 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 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 at 6:59
add a comment |
user10777668 is a new contributor. Be nice, and check out our Code of Conduct.
user10777668 is a new contributor. Be nice, and check out our Code of Conduct.
user10777668 is a new contributor. Be nice, and check out our Code of Conduct.
user10777668 is a new contributor. Be nice, and check out our Code of Conduct.
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f487458%2fsort-not-sorting-lines-with-a-pipe-in-it-correctly%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
2
use
LC_COLLATE=C sort. Depending on what you're expecting, you may also needLC_COLLATE=C sort -t'|' -n– mosvy
Dec 11 at 22:49
3
To sort "csv style" data you may want to use
csvsortfromcsvkit, which properly handles quoted values.– Bakuriu
Dec 12 at 8:17