It annoys me having used Unix in college and now working on the Windows side. What’s the history behind this decision? Anyone know why it worked out this way?
Solution:
Unix introduced /
as the directory separator sometime around 1970. I don’t know why exactly this character was chosen; the ancestor system Multics used >
, but the designers of Unix had already used >
together with <
for redirection in the shell (see Why is the root directory denoted by a /
sign?).
MS-DOS 2.0 introduced as the directory separator in the early 1980s. The reason
/
was not used is that MS-DOS 1.0 (which did not support directories at all) was already using /
to introduce command-line options. It took this usage of /
from CP/M, which took it from VMS. You can read a more thorough explanation of why that choice was made on Larry Osterman’s blog (MS-DOS even briefly had an option to change the option character to -
and the directory separator to /
, but it didn’t stick).
/
it is recognized by most programmer-level APIs (in all versions of DOS and Windows). So you can often, but not always get away with using /
as a directory separator under Windows. A notable exception is that you can’t use /
as a separator after the \?
prefix which (even in Windows 7) is the only way to specify a path using Unicode or containing more than 260 characters.
Some user interface elements support /
as a directory separator under Windows, but not all. Some programs just pass filenames through to the underlying API, so they support /
and indifferently. In the command interpreter (in
command.com
or cmd
), you can use /
in many cases, but not always; this is partly dependent on the version of Windows (for example, cd /windows
works in XP and 7 but did not in Windows 9x). The Explorer path entry box accepts /
(at least from XP up; probably because it also accepts URLs). On the other hand, the standard file open dialog rejects slashes.