sort / Sorting order differs from gnusort (CR/FF)
Open
Nobody has claimed this yet.
U - sort
- Dominant language
- Rust
- Stars
- 24.1k
- Forks
- 2k
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 365
Description
While sorting large files I noticed a different order compared to gnusort. Took some time to create short test cases, here they are:
# ./coreutils --version
coreutils 0.10.0 (multi-call binary)
# gnusort --version
sort (GNU coreutils) 9.7
Packaged by Ubuntu (9.7-3ubuntu2)
Sort by key:
# printf 'aa\n0aa\r\n' | gnusort -k2,3
0aa
aa
# printf 'aa\n0aa\r\n' | ./coreutils sort -k2,3
aa
0aa
Dictionary order:
# printf 'a\rb\naab\n' | gnusort -d
aab
b
# printf 'a\rb\naab\n' | coreutils sort -d
b
aab
Same with numerical sort:
# printf '\r4\na\n' | gnusort -n
4
a
# printf '\r4\na\n' | coreutils sort -n
a
4
I suspect CR and FF treated as blanks?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the three reported cases with the coreutils sort command and compare each result with GNU sort. Investigate how sort handles carriage returns and form feeds during key, dictionary, and numerical comparisons. Done means the listed inputs produce the same ordering as GNU sort.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 72/100