If I understand the article, the author wants magic :)
I take it to mean they want the system to know file_9.txt is less then file_10.txt.
I never saw that happen in any OS, so I do not know what he is referring to. Maybe whatever that old system was, it sorted by create time as opposed to file name.
So, the author can try and create "aisort" that will look at all file names and add leading zeros to the file numeric portion, sort, then remove the zeros added. That will probably as slow as s***t and use gobs pf memory, depending on the number of files.
Author here - My surprise stems exactly from the fact that for the last few years I have exclusively managed my files via a the UNIX shell, which behaves in the classical way.
When I started using Linux as my daily driver after many years of Windows (but with familiarity with UNIX systems going way back), I knew it would be like that in the terminal, but it still took some adjustment. But actually, Nemo does the same "natural sort" thing, and also sorts case-insensitively.
That's not what the author says- they said that file managers actually are somehow sorting file-9.txt before file-10.txt, and it's breaking real alphabetical ordering.
i think it's the opposite, that they _want_ file_10.txt to come before file_9.txt by default, but that file explorers fail at this. it's rare that i want true alphabetical sort, but it's convenient for cases like tfa where alphabetical sort is more predictable if i have filenames that look like <letters>_<numbers-of-same-length>.txt.
I take it to mean they want the system to know file_9.txt is less then file_10.txt.
I never saw that happen in any OS, so I do not know what he is referring to. Maybe whatever that old system was, it sorted by create time as opposed to file name.
So, the author can try and create "aisort" that will look at all file names and add leading zeros to the file numeric portion, sort, then remove the zeros added. That will probably as slow as s***t and use gobs pf memory, depending on the number of files.