The sad thing is Microsoft never wanted the backslash. It's all IBM's fault.<p>DOS 1.0 had no subdirectories. There was no slash: you didn't type A:\FOO.TXT, you typed A:FOO.TXT, and the prompt wasn't A:\>, but rather A>. Incidentally, this still works today, and sometimes DOS boots with a A> prompt.<p>In DOS 2.0, Microsoft decided to add UNIX-style directories, with . and .. for navigation, / as the separator, cd to change directory and so on. But there was a problem.<p>DOS 1.0 had used / for flags (e.g. DIR /W). Microsoft's solution to this was to switch to - for flags, but IBM didn't like this change. So Microsoft compromised on using \ as the directory separator and kept / in use for flags.<p>However, Microsoft clearly didn't like having to make this change. How do we know this? Well, DOS nonetheless also supported / for directories (and thus its successors, including Windows NT do), and, at least for a little while, contained a setting which let you use - as the flag character.
So the thing is, low-level Windows APIs (such as CreateFile) have supported forward slashes for a <i>long</i> time. And since libc/posix-ish stuff like fopen() is implemented with that API on Windows, nearly all programming languages are magically forward/backslash agnostic on Windows. As a programmer, this means that in places where it really matters, you're usually just fine with forward slashes.<p>Many UIs get confused on forward slashes though (file open dialog, stuff like that), and given that the vast majority of people, worldwide, that understand what files and directories are, believe backslashes are the way to go, I doubt MS is ever going to change this.<p>But from personal experience - I've programmed cross-platform stuff on Windows for very many years, and I never bothered about backslashes. In all honesty I never understood all the open source stuff that comes with DIRECTORY_SEPARATOR global constants or eslint rules that tell you to use path.join() instead of `dir + "/" + subdir`. The forward slash just works, and it has worked for ages.<p>The only "problem" is that at times you end up concatenating paths together and end up with stuff like<p><pre><code> C:\Temp/mydir/2/..\file.txt
</code></pre>
That's a bit quirky in log file and in the debugger. But fopen eats it just fine.<p>Sure there might be cases where this is a problem, probably the libraries I've seen code around backslashes have good reasons, but really for end-programmers it's no biggie.<p>Now, MAX_PATH, that's something else. <i>That</i> should die in a fire and it blows my mind that it hasn't been addressed yet.
Forward slash has worked just fine on Windows for a LONG time. Backslash will probably still be around in the year 3,000 for backwards compatibility though.
Many Windows commands use "/" to introduce options (much like most Unix commands use "-"). Since the default command shell doesn't require whitespace after the command name and permits options to follow other arguments, it would be difficult to use "/" as a directory separator in all cases.<p>An example from Microsoft's documentation:<p><pre><code> dir c:\*.txt /w/o/s/p</code></pre>
The best part of using backslashes in paths is that for character encoding historical reasons, backslashes are printed as ¥ in Japan.<p>C:¥Windows¥System32.
It would be nice if we could get Windows internally to use paths like / for the C drive and then use /mnt/d for the D drives, and use Bash as the default shell instead of cmd.exe. I suspect it will take some time, but if they do so, it would make Windows a first-class POSIX development setup.<p>I can only imagine the difficulty of something like this, given all the legacy code and backward compatibility issues. Perhaps intelligently rollback to C:\ style paths when apps use backslashes. For Program Files, they might as well continue using /Program Files/ since it's not all too different from /opt.
I thought this was about people still misreading URLs more than 20 years since the popularization of the web as "example-dot-com-backslash-tour"<p>I've never understood that. The only way I could explain it in the 90s was because "computers use backslashes" due to the ubiquitousness of DOS and Windows paths. Now, who types a path on their local machine besides developers using a command line?
I don't even have a working Windows image to try the new bashy goodness, but this was my first thought when it was announced: what about the slash/backslash difference? But even twenty years ago, bouncing back and forth between DOS/Windows and some flavor of Unix, I wished MSFT would get with the program and ditch the hard-to-reach backslash.
I think this post is a little bit confused, since it talks about Bash in Windows, but I've seen no evidence that Bash supports backslash as a path separator in Windows. I agree it's unfortunate that backslash paths are still around, but I guarantee you that won't be the most annoying issue with running Linux userspace tools on Windows.
The really sucky thing about working on Windows is the paths. On Linux my applications are in /opt or /usr/apps. On Windows the path names seem super long and include all sorts of parens and spaces and such.
Why is backslash called BACK slash when it actually points forward?<p><a href="http://ux.stackexchange.com/questions/92390/why-is-backslash-called-back-slash-when-it-actually-points-forward" rel="nofollow">http://ux.stackexchange.com/questions/92390/why-is-backslash...</a>