Having two days experience I can safely state that Windows decision to go case insensitive for path and file names was a stroke of genius! And then why / when you could equally \ or indeed be \/ ambivilant? It is a tribal thing I am sure.
Basically, the difference came about as parallel evolution, and the differences stay due to backwards compatibility. (Especially on the Windows side of things.)
On the UNIX side of things, UNIX was written in C and assembly language, and had a directory-based filesystem from the very start, in 1969.
In C, backslash('\') is an escape character for strings, used to indicate that the next character should be interpreted in some special way. You would use it to either indicate that the compiler should add a special character to the string, or should treat the next character as part of the string and not as part of the code. For example, to have a string with quotes in C, you would put a backslash in front of the embedded quotes to indicate that they were supposed to be part of the string, not part of the code.
printf("What is the definition of \"word\"?");
Would output
What is the definition of "word"?
You also use escape sequences to add things like newlines:
printf("This is one line\nThis is another line");
Would output
This is one line
This is another line
If you want to have a backslash in a string, you need to escape it:
printf("Test\\Backslash");
Would output
Test\Backslash
.
Also, UNIX had the philosophy that EVERYTHING is a file. EVERY interaction you do with the system is done by manipulating it as a file in some way. Therefore, files(and directories) get used a LOT.
So, they used the forward slash as the path separator, so you don't have to double-up on the backslashes.
If you have a gpio folder, in a class folder, in the top-level sys folder, if you had to reference it using backslashes, you'd have to do this:
FILE * f = fopen("\\sys\\class\\gpio", "r");
If you didn't, the escape characters would get eaten up by the compiler, and you'd end up with (roughly) this:
FILE * f = fopen("sysclassgpio", "r");
Not exactly gonna help you,
So, forward slashes were decided as the separator.
FILE f = fopen("/sys/class/gpio", "r");
That's carried through to every UNIX-derived and UNIX-clone system, including Linux and BSD(and derivatives).
Also, UNIX was case-sensitive when it was first written, mainly for code simplicity reasons. It's a lot more work to create a case-insensitive system than a case-sensitive one, and it just gets worse when you start dealing with internationalization.
Oh, and by UNIX convention, the dash character('-') was used to indicate an argument to a program, e.g. "cp -r folder1 folder2" to recursively("-r") copy one folder to another.
On the MS-DOS side of things, there are a few very important things to know: the original MS-DOS(86-DOS before Microsoft bought it) was created to be a clone of/compatible with Digital Research's CP/M, and thus inherited all of CP/M's quirks, and it was written purely in x86 assembly language, so they didn't need to worry about C-style string escaping. (Later versions of MS-DOS included C code, but the system was already set in stone by then.)
The quirks MS-DOS 1.0 inherited from CP/M were:
- Case-insensitive filesystem. Actually, this isn't quite true. The filesystem WAS case-sensitive, but the only case you had was UPPERCASE. There was no way to create files that had lowercase characters in them. If you tried, the FS would convert lowercase to uppercase before accessing the disk. (Later versions of MSDOS were, I believe, case-preserving: it would create the file exactly as you specified, but when accessing files, everything was converted to uppercase before comparing filenames. Therefore, it seemingly became "case-insensitive".)
- Program argument character was forward slash("/"), e.g. "COPY /Y FILE1 FILE2" to force-override an existing file.
- NO directories. Seriously, there were so such things as folders/directories in CP/M, or in MS-DOS 1.0. You just had different drive letters, and all files were placed in the root of the drive(since they literally could not go anywhere else). You used the colon(":") to separate the drive letter from the filename.
So, to access the file TEST.TXT on your floppy, you'd do "A:TEST.TXT".
When later versions of MS-DOS added subfolders/subdirs, the backslash character was chosen because 1) assembly, therefore no escape character problem, and 2) the forward slash was already taken by the argument indicator, and if you used forward slashes in paths, you might confuse programs doing command-line parsing.
With Microsoft's dedication to backwards compatibility, all of these quirks were carried forward, even into today's systems.
Heck, the NT kernel and filesystem layer ARE case-sensitive! The Win32 layer has to do extra work to behave case-insensitively, because that's what programs expect!
This is also why, when you're doing file programming on Windows in C/C++, you DO have to do all that weird double-backslash stuff.
FILE * f = fopen("C:\temp\test.txt", "r");
That won't work on Windows! You have to do:
FILE * f = fopen("C:\\temp\\test.txt", "r");
As for systems becoming agnostic to the slashes, well, funny thing is, Windows(the Win32 subsystem and API) ARE agnostic! For the most part, anything that handles files can use backwards OR forwards slashes, and Windows won't care.
(A LOT of programs will break doing this, but that's because of the programs not expecting forward slashes.)
If you use the Win32 API, passing "C:/temp/test.txt" in to CreateFile() will work just fine.
In C/C++, THIS will work just fine:
FILE * f = fopen("C:/temp/test.txt", "r");
As for the Linux side of things... that's a bit more difficult.
First, not only C, but the shell uses '\' as an escape character. You can access a path with spaces by either quoting the path, or escaping the spaces.
cd "Liberty BASIC"
cd Liberty\ BASIC
These both will change to a folder named "Liberty BASIC".
If you're coding(in C, for example), you have to use forward slash as your path separator. If you try to use a backslash, things get... weird.
It won't
fail, but it won't work, either.
If you try, for example, to create a file "folder\\test.txt", instead of putting a file named "test.txt" in the subfolder "folder", it will create a file named "folder\test.txt" in the current directory, and the "folder" directory will be empty, because a backslash is a valid character in a UNIX filename. Yeah.
Historical weirdness on all sides, basically.
And wow, I did not mean for this post to get this big. Oops.