
Backslash must die - chris-at
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13314285-backslash-must-die
======
TazeTSchnitzel
The sad thing is Microsoft never wanted the backslash. It's all IBM's fault.

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.

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.

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.

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.

~~~
wolfgke
A more detailed representation of this topic:
[http://www.howtogeek.com/181774/why-windows-uses-
backslashes...](http://www.howtogeek.com/181774/why-windows-uses-backslashes-
and-everything-else-uses-forward-slashes/)

P.S.: VMS/OpenVMS, which was designed by David Cutler (the same guy who later
designed Windows NT after he was poached by Microsoft), used . as directory
separator
([https://en.wikipedia.org/w/index.php?title=Files-11&oldid=68...](https://en.wikipedia.org/w/index.php?title=Files-11&oldid=680322555))

~~~
simula67
Comments in TFA also links to an official source
[https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...](https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-
is-the-dos-path-character/)

~~~
wolfgke
Thanks, this was the article I was originally looking for.

------
skrebbel
So the thing is, low-level Windows APIs (such as CreateFile) have supported
forward slashes for a _long_ 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.

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.

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.

The only "problem" is that at times you end up concatenating paths together
and end up with stuff like

    
    
        C:\Temp/mydir/2/..\file.txt
    

That's a bit quirky in log file and in the debugger. But fopen eats it just
fine.

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.

Now, MAX_PATH, that's something else. _That_ should die in a fire and it blows
my mind that it hasn't been addressed yet.

~~~
capote
Do you have a source on "vast majority of people ... believe backslashes are
the way to go"?

And if you do, do you have a source on why?

Also, yeah, can anyone clarify what the deal with the max path length is? And
why it's possible to create a path above the max length but not to simply
delete it from the filesystem?

~~~
SBArbeit
Probably no source other than: there are 1B+ Windows users (like me) vs. maybe
100M Mac users + a few million Unix-y users.

~~~
jdietrich
What proportion of Windows users actually deal with file paths on a regular
basis?

~~~
monochromatic
Out of people young enough to have missed everything prior to Windows 95, I'd
bet that easily 90% have never typed a file path.

~~~
jack9
Almost every single working person who deals with URLs or buys things
online...or uses facebook has typed a file path styled URL.

------
Animats
And, after that, kill CR LF as a line separator. That's an idea which belongs
to the era of mechanical Teletype machines.

~~~
skissane
CR LF is the Internet standard, however. TELNET, SMTP, FTP, and most
significantly HTTP/1.1 all specify CRLF is to be used as the line terminator
(not LF). Many popular implementations will accept a bare LF as well, but
messages containing a bare LF are strictly not standards conforming.

Given this is fixed in RFCs, it is unlikely to ever change

~~~
stormbrew
This is not why Windows uses CRLF, nor is it some original reason that is now
obsolete. It was standard for both DOS' predecessors and early internet
standards because teletypes considered carriage return and linefeed separate
commands, and both were built to operate with those things.

None of that stopped UNIX from getting away from it, and the internet is
basically built on UNIX. What transformations the C FILE stream implementation
makes to linefeeds has nothing at all to do with TELNET, SMTP, FTP, or HTTP.
These are very separate areas of concern. In Windows if you're writing socket
code you have to explicitly write the \r and the \n, just like on any other
platform.

~~~
skissane
"the internet is basically built on UNIX" is an odd thing to say. In the early
days of the Internet (early 1980s, 1970s if we want to include ARPANET as the
current TCP/IP-based Internet's predecessor), it was a very diverse place,
with lots of DEC operating systems (TOPS-20, VMS), IBM mainframes, and various
other mainframe and minicomputer vendors, with Unix by no means predominating.
The Unix monoculture (and later Unix/Windows biculture) grew through the 1980s
and was well-established by the 1990s. Major protocols such as IP, TCP, UDP,
TELNET, FTP and SMTP were all developed prior to that Unix monoculture taking
hold. FTP in particular shows the pre-Unix heritage very clearly, with support
for record-oriented filesystems (STRU R, MODE B, MODE C) for DEC and IBM
operating systems, support for systems that don't use 8-bit bytes (e.g. TYPE
L36), built-in ASCII-EBCDIC translation (TYPE A and TYPE E), support for ASA
carriage control (TYPE A C and TYPE E C), and support for TOPS-20 paged files
(STRU P). (These are all features pretty meaningless on Unix systems, which is
why Unix FTP clients and servers largely do not implement them.)

~~~
stormbrew
Feel free to insert "as we know it", because I do not believe that the
pre-1980s internet is recognizably the same thing. I will not strongly argue
the point since I wasn't there.

But to clarify on the salient part, I was trying to say that UNIX diverged
(successfully) from what came before it, and the CRLF behaviour was from the
teletype era that the early internet started in. My point about UNIX being a
building block of the (modern) internet was more about pointing out that if
UNIX could diverge from that and be a key component of the internet, it's
absurd to think that Windows could not.

I can definitely understand how you got where you did from what I said,
though.

~~~
groovy2shoes
Thing is, UNIX _also_ came from the same teletype era that the early Internet
started in.

------
monochromatic
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.

~~~
chris-at
You should say it 'works sometimes'.

I actually forgot where it works because

\- if I try to open a file `i:/foo/bar/test.txt` I get `The file name is not
valid` (from Notepad)

\- if I try to open a folder `i:/foo/bar` I get `The folder name is not valid`

\- if I try to `cd /foo/bar` I get `The system cannot find the path
specified.`

~~~
anexprogrammer
It doesn't help that the various Windows dialogues treat '/' differently.

Windows really should have _just one_ file open dialogue, etc.

~~~
wlesieutre
I _hate_ that reimplementing the open dialog is an acceptable practice on
Windows. I have one dialog in Acrobat, another one in AutoCAD, another for
AGI32, and (I think the standard one) in Chrome. Probably others that I'm
forgetting.

Each of these has its own special list of "favorites" on the left, so if I
want to add a shortcut to a commonly used folder, I find myself doing it in 8
different places. Or in some cases I can't; Acrobat has a sidebar with large
icons of Recent Places, Desktop, Libraries, Computer, and Network. If you
wanted to add somewhere more useful, you're shit out of luck.

Anyone know why this happened? Was there a period around Windows XP where the
built in dialog was just godawful and everyone said "Fine I'll make my own"
and then they never went away?

Compare to OS X where any time someone rolls their own dialogs for system
features (especially Open and Print), I immediately assume the developer is an
asshole. And for the most part, nobody does it. The only one I can think of
off the top of my head is printing from Chrome, and theirs even includes a
"Print using system dialog…" button.

~~~
anexprogrammer
It's been one of my many pet hates about Windows since first having to use it
regularly, around NT or 2000. Windows isn't even consistent _with itself_ over
the look of things bringing elements of previous and future versions of
Windows to your desktop.

To add to the sibling comments...

From MSDN _" Windows continues to support the old-style Open dialog box for
applications that want to maintain a user-interface consistent with the old-
style user-interface"_

No, no and thrice no. If I'm on Win 7, _everything_ should look Win 7
consistent. Likewise if I'm on 10 it should all look 10, perhaps with
necessarily reduced functionality if it's a deprecated call.

If I'm running Visual Studio on 7, I don't want all my icons, and GUI to be of
10. No matter how diligently you upgrade, there is always something visually
out of step. Even with only MS software.

I suspect it was the very late arrival of a Windows Style Guide made a lot of
developers get the habit of doing their own thing. Then they'll start faffing
around with variations so you can have preview in open. Hell, might as well do
our own everything. The rules didn't say you shouldn't.

Mac always had a pretty tight, and extensive, Style Guide with apparently
thought down to individual pixels; Windows seemed not to care, or not
understand when it did care. Around XP Windows started caring more about UX,
but probably far too late.

~~~
xorblurb
More than a decade ago, MS used to kind of have that, and mostly consistent at
the architecture level, but I think it was only by chance (win 3.1 programs
still had all their legacy dialogs, including open file), because they just
did not have had the time yet to implement 1000 different graphical frameworks
for example, or to evolve dozens of ribbon interfaces from various unrelated
teams. Now it is nothing else than an absolute mess: Win32 programs are very
different from UWT stuff (and not just the drawing of the control, the whole
interaction model is completely different), and you've also got layers of
unrefreshed designs inherited from the guidelines (or informal practices) of
the day of the version of windows the component was first introduced in, with
inspiration flowing from other teams (or even other systems) but with no
common technical framework continuously shared between them, so for example
Office also has its very own stuff.

This is a big difference, and in the end a classical one, in the way companies
typically work compared to open source projects (not just open source code,
I'm really talking about the whole project being open): in companies teams or
individuals just don't collaborate as much, because projects are often
extremely closed even within the companies, with all kind of access rights.
And also some app team might want to support really old OS (who uses a Linux
distro of 2009 today? Well, OTOH tons of people are using a Windows version
from 2009...) for a few more years and that OS certainly won't add any kind of
support for the UI the app guys want, and the app guy might not want to use
loads of resource to make their app look neatly graphically integrated in old
OSes.

In summary, for proprietary stuff, this is an hard problem both at the
technical and at the organizational level, especially if you like to change
your graphic experience so often like MS does. And now everybody is used to
seeing widely inconsistent stuff on the same screen anyway, so old on new /
new on old / different on different cases will remain, I guess. Plus
converging UI from vastly different devices is also a hard problem in itself,
and UWP is actually not bad at it -- but the price is obviously that it must
be irrecoverably different from old Win32 programs.

~~~
anexprogrammer
That's true, I'd forgotten. Win 2k was fairly consistent about things, and
even XP had a fairly decent classic fallback mode.

I understand a lot of the baggage they're carrying for keeping compatibility
and suffering 20 year old choices etc. I can't help but feel that 7 or 8
should have drawn a hard MacOS/OSX like line under things and given us a
modern windows with newer choices. Add a VM for running your old XP app. Throw
cmd and dos away entirely.

I actually respect MS for being brave enough to experiment with the GUI as
much as they have, yes and get it terribly wrong sometimes. A classic
fallback, or a 7 fallback for 8 would have made the 8 fail easier to bear.

Not entirely sure the company / open comparison is the whole story. Someone
somewhere designed metro (or 7, or 10), figured out a UI and design language,
and had some principles behind it. Those could be made the contract for the
team's software being seen in the world. Again Windows has it more complex as
so much of the GUI ends up in the .exe, so what you see is when it was made
not what it runs on.

I think you're right in that having got where we are, it's unlikely to easily
improve.

------
_kst_
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.

An example from Microsoft's documentation:

    
    
        dir c:\*.txt /w/o/s/p

~~~
ChrisDutrow
I'm not sure if this normal or not, but I have a lot of trouble telling the
back slash and forward slash apart.

~~~
kolinko
Either your system font is weird, or you're dyslectic. Seriously.

~~~
sp332
*dyslexic

------
glandium
The best part of using backslashes in paths is that for character encoding
historical reasons, backslashes are printed as ¥ in Japan.

C:¥Windows¥System32.

------
jasonjei
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.

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.

~~~
Arnavion
You _can_ mount drives at empty directories in other drives, just like Unix. I
have C: on an SSD and mount a HDD at C:\Stuff

I remember one installer that didn't understand this (I think it was Steam)
and concluded it wouldn't install to C:\Stuff\foo because there was
insufficient disk space under C: - it was looking at the free space of C: (the
SSD) instead of C:\Stuff .

There's also plenty software out there that confuses volumes with drives and
tries to enumerate the latter when it should be enumerating the former.

------
jonathankoren
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"

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?

------
d33
Would that involve also adding smb://HOSTNAME as opposed to \\\HOSTNAME?

~~~
hug
PS C:\> cd ~/..

PS C:\Users> cd /

PS C:\> cd //localhost/c$

PS Microsoft.PowerShell.Core\FileSystem::\\\localhost\c$>

------
mikestew
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.

~~~
throweway
And the path length limitation

~~~
guy1543
Windows already does accept forward slash in paths and has for a while. The
back slash still lives for legacy applications and unfortunately probably will
for a long long time.

~~~
hackuser
How is it possible I didn't know that? Thank you. Does anyone know the history
of it? I did a little research:

* I found someone asking the same question as me in 2005 (!) [1]

* Per someone on Stack Overflow: "/ can be used as a path separator at the API level, but you aren't calling the API directly. You're using cmd.exe, and cmd.exe parses the / as a command line option" [2]

* Later in the same Stack Overflow discussion someone performs a series of tests on Vista, with some inconsistent results. [2]

* Here's a history by veteran Microsoft developer Larry Osterman, which takes us back to the developers of MS-DOS and also mentions other undocumented ways MS-DOS can/could be made Unix friendly. [3]

\-----

[1] [https://bytes.com/topic/python/answers/23123-when-did-
window...](https://bytes.com/topic/python/answers/23123-when-did-windows-
start-accepting-forward-slash-path-separator)

[2] [https://stackoverflow.com/questions/10523708/why-does-the-
cm...](https://stackoverflow.com/questions/10523708/why-does-the-cmd-exe-
shell-on-windows-fail-with-paths-using-a-forward-slash)

[3]
[https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...](https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-
is-the-dos-path-character/)

~~~
pwg
> How is it possible I didn't know that? Thank you. Does anyone know the
> history of it? I did a little research:

According to the history, DOS 2.0:

[https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...](https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-
is-the-dos-path-character/)

[begin quote] Here’s a little known secret about MS-DOS. The DOS developers
weren’t particularly happy about this state of affairs – heck, they all used
Xenix machines for email and stuff, so they were familiar with the _nix
command semantics. So they coded the OS to accept either “ /” or “\” character
as the path character (this continues today, btw – try typing “notepad
c:/boot.ini” on an XP machine (if you’re an admin)). And they went one step
further. They added an undocumented system call to change the switch
character. And updated the utilities to respect this flag.

And then they went and finished out the scenario: They added a config.sys
option, SWITCHAR= that would let you set the switch character to “-“.

Which flipped MS-DOS into a _nix style system where command lines used
“-switch”, and paths were / delimited. [end quote]

------
skywhopper
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.

------
gozur88
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.

~~~
fowl2
That was intentional to force programs to work with spaces and "special"
characters.

~~~
Stratoscope
Naw, it was just to give users "friendlier" directory names like "Program
Files" and "Documents and Settings".

------
dandare
Why is backslash called BACK slash when it actually points forward?

[http://ux.stackexchange.com/questions/92390/why-is-
backslash...](http://ux.stackexchange.com/questions/92390/why-is-backslash-
called-back-slash-when-it-actually-points-forward)

