I agree that it does “the right thing”, that is it behaves as documented. But that “right thing” could be surprising to a human.
There’s ls -v which does “version sort” which would seem like a more reasonable default, at least for human consumption. I know it’s impossible to change now because a bajillion tools all over the place depend on the sort order.
❯ touch `seq 1 100` ❯ ls 1 18 27 36 45 54 63 72 81 90 10 19 28 37 46 55 64 73 82 91 100 2 29 38 47 56 65 74 83 92 11 20 3 39 48 57 66 75 84 93 12 21 30 4 49 58 67 76 85 94 13 22 31 40 5 59 68 77 86 95 14 23 32 41 50 6 69 78 87 96 15 24 33 42 51 60 7 79 88 97 16 25 34 43 52 61 70 8 89 98 17 26 35 44 53 62 71 80 9 99
(Do I need to tell you how many times I fucked up like this myself?)
Those are file names, there’s no reason to assume that they would be numerical which is why ls does the right thing.
I’m of the opinion that if you want to store numbers as strings and also sort them, you give them a fixed length and leading zeroes.
I agree that it does “the right thing”, that is it behaves as documented. But that “right thing” could be surprising to a human.
There’s
ls -v
which does “version sort” which would seem like a more reasonable default, at least for human consumption. I know it’s impossible to change now because a bajillion tools all over the place depend on the sort order.However new tools like
eza
do this by default:❯ ls -l | sort -n
Shouldn’t that work correctly?