You may also want to try, for example, the files “a1”, “a2”, “a3”, and “a10”. Lexicographically, “a2”>“a10”, but my file browser displays “a10” after “a2”.
I’m with you, and not just from a “human” perspective. Also when writing small programs meant to be relatively lean/simple it can be a problem when the user expects it to find a particular file regardless of its case (will it be DOOM.WAD or doom.wad? Doom.wad? Doom.WAD? … guess it’ll have to be [Dd][Oo][Oo][Mm].[Ww][Aa][Dd] and import some globbing library as extra dependency… that, or list the whole directory regardless its size and lower/upper every single filename until you find a matching one…)
Oh jeez, I hadn’t even thought about capitalisation in the file extension. That would be especially confusing if extensions are hidden- the user would be presented with two files that look exactly the same.
if you look for a file you type the first letters for the file explorer to jump to the matching name. Retype to jump to the next fitting entry. If you don’t know about this, you can put your string in the search field. If you don’t know about this, you can sort by metadata like file size or date of last change.
It is a non problem.
Also most workplaces tend to develop a file naming convention, either explicitly or implicitly.
But do I type ‘ImportantFile’, or ‘importantfile’?
As I understand it, if I searched for either of these strings in a case sensitive file system, I would not find a file called ‘IMPORTANTFILE’.
At best, a case sensitive file system makes naming conventions more complex. At worst , it obfuscates files. I just can’t imagine a scenario where it would be helpful. Do you really see a need to have a file called ‘aaaAaa’ and a totally separate one called ‘aaAaaa’?
But then you are not getting rid of the complexity, you are just forcing programs to become more complex/inefficient.
I experienced this with the doom libretro core, which is meant to be portable and have minimal dependencies… so if I need it to automatically find DOOM.WAD/ doom.wad/Doom.WAD/etc in a directory I would either have to add a globbing library as dependency to handle this case and have it fetch [Dd][Oo][Oo][Mm].[Ww][Aa][Dd], manually check for each possible case, or list the entire directory (I hope you don’t have a library of a million wads!) and compare each file (after upper/lower) just to find the one with the right name. And that could be a real pain for embedded devices with low I/O or if there’s a remote storage layer behind.
I think we are looking at this from different angles. I think you are looking at the programmer perspective, and i am looking at the end-user perspective, who uses a GUI file explorer.
In the case of a GUI file explorer the search handles the case insensitivity. So for me using Dolphin in KDE if i have two files:
TEST.txt and test.txt, if i type “tes” on my keyboard, i will be given the uppercase one first. if i type “te” again, it jumps to the next fitting entry, which is test.txt. If i put “test” or “TEST” in the search bar, i will get back both results.
I see why a strictly case insensitive file system makes it easier for programmers down the line to not have to handle the different cases explicitly in their program anymore.
If I have four files, a.txt, A.txt, b.txt, and B.txt, in what order do they appear when I sort alphabetically?
edit: I don’t understand why this was downvoted?
Might depend on your file browser.
You may also want to try, for example, the files “a1”, “a2”, “a3”, and “a10”. Lexicographically, “a2”>“a10”, but my file browser displays “a10” after “a2”.
a, A, b, B?
A computer will spit out A, B, a, b
See also: ASCII chart
So if someone tells me to look for a file amongst a long list, I need to look in two different areas- the uppercase and lowercase areas.
I get why it’s more technically correct to differentiate, but from the perspective of a human user, it’s a pain in the ass.
I’m with you, and not just from a “human” perspective. Also when writing small programs meant to be relatively lean/simple it can be a problem when the user expects it to find a particular file regardless of its case (will it be
DOOM.WADordoom.wad?Doom.wad?Doom.WAD? … guess it’ll have to be[Dd][Oo][Oo][Mm].[Ww][Aa][Dd]and import some globbing library as extra dependency… that, or list the whole directory regardless its size andlower/upperevery single filename until you find a matching one…)Oh jeez, I hadn’t even thought about capitalisation in the file extension. That would be especially confusing if extensions are hidden- the user would be presented with two files that look exactly the same.
if you look for a file you type the first letters for the file explorer to jump to the matching name. Retype to jump to the next fitting entry. If you don’t know about this, you can put your string in the search field. If you don’t know about this, you can sort by metadata like file size or date of last change.
It is a non problem.
Also most workplaces tend to develop a file naming convention, either explicitly or implicitly.
But do I type ‘ImportantFile’, or ‘importantfile’?
As I understand it, if I searched for either of these strings in a case sensitive file system, I would not find a file called ‘IMPORTANTFILE’.
At best, a case sensitive file system makes naming conventions more complex. At worst , it obfuscates files. I just can’t imagine a scenario where it would be helpful. Do you really see a need to have a file called ‘aaaAaa’ and a totally separate one called ‘aaAaaa’?
The search string is case insensitive. The file name isnt.
So you will find all of them.
But then you are not getting rid of the complexity, you are just forcing programs to become more complex/inefficient.
I experienced this with the doom libretro core, which is meant to be portable and have minimal dependencies… so if I need it to automatically find
DOOM.WAD/doom.wad/Doom.WAD/etc in a directory I would either have to add a globbing library as dependency to handle this case and have it fetch[Dd][Oo][Oo][Mm].[Ww][Aa][Dd], manually check for each possible case, or list the entire directory (I hope you don’t have a library of a million wads!) and compare each file (afterupper/lower) just to find the one with the right name. And that could be a real pain for embedded devices with low I/O or if there’s a remote storage layer behind.I think we are looking at this from different angles. I think you are looking at the programmer perspective, and i am looking at the end-user perspective, who uses a GUI file explorer.
In the case of a GUI file explorer the search handles the case insensitivity. So for me using Dolphin in KDE if i have two files:
TEST.txt and test.txt, if i type “tes” on my keyboard, i will be given the uppercase one first. if i type “te” again, it jumps to the next fitting entry, which is test.txt. If i put “test” or “TEST” in the search bar, i will get back both results.
I see why a strictly case insensitive file system makes it easier for programmers down the line to not have to handle the different cases explicitly in their program anymore.
Why would you order lowercase before uppercase?
Ascending order implies going from low to high
I guess the problem is that they were thinking First to Last when putting it in this order. Kind of like the image here: