10 ms·
Why Does Windows Use Backslash as Path Separator? (2019)
- gdulli 5y agoAre there contexts where the backslash is still required? I've been using the forward slash in Windows for years. It works from Python, it works from the command prompt, it works in Explorer. But I don't know if that means it's completely redundant or if some places still require it.
- Something1234 5y agoIt doesn't tab complete the path if you use forward slash in windows batch. I think forward slash works right in PowerShell, but I might be mistaken.
- mshockwave 5y agoit works just fine in PowerShell and the new Windows Terminal but yeah, I doubt CMD will do auto-complete for you w/ forward slash
- EvanAnderson 5y agoIt will not. It completes out of the current directory when trying to TAB-complete following a slash.
- infogulch 5y agoPowershell will autocomplete forward-slash paths and convert them to back slashes.
- dfawcus 5y agoAt the API level, both '/' and '\' have been accepted since sub-directories were added to DOS. It was only ever at the UI (command prompt), and in how some programs converted inputs and outputs where '\' was necessary, as the knowledge about '/' being usable wasn't all that widespread. What used to peeve me was C source on DOS development environments with lines like: #include "path\\to\\file.h" When the following always seemed to work (with the compilers I used): #include "path/to/file.h" Or at least it did with Borland compilers.
- edgyquant 5y agoThis post isn’t about file paths but command line arguments
- electroly 5y agoBecause the forward slash is used for command line flags, there can be ambiguity when using forward slashes in paths that does not exist if using backslashes. Consider a directory on your root C: drive called "D". In a command prompt: cd \D <-- This takes you to the C:\D\ directory. cd /D <-- This is an error because /D is a flag.
- paulmooreparks 5y agoTrue, but quoting the path will work: cd "/D"
- adtac 5y agoHow? Wouldn't the program's argv see the same string with and without quotes? Or is that just a *nix thing?
- schroeding 5y agocd is a built-in of the shell / cmd, not an application, it does not use argv, AFAIK. It should, as you said, not work for normal applications
- johnny22 5y agonope. I read an article about this when i accidentally broke the arg parsing for wildcards. worked fine in linux, but not on windows :(
- int_19h 5y agoIn Win32, argv is not part of the OS process API. The processes get the entire command line as a string, and have to parse it themselves - or, more commonly, leave it up to the C runtime. But in this case, I don't think it matters.
- DrBazza 5y agoThis is interesting regarding args. https://nullprogram.com/blog/2022/02/18/ https://nullprogram.com/blog/2022/02/18/
- joshuaissac 5y agoThey are still needed in UNC paths like \\server\...\.
- dgrunwald 5y agoUNC paths like //server/share/ are perfectly fine.
- deleted 5y ago[deleted]
- joshuaissac 5y agoI tried it in Windows Explorer on Windows 10, and it just launches the browser for me instead of opening the folder.
- EvanAnderson 5y agoCMD and Windows Explorer don't like that. Powershell handles it fine.
- edflsafoiewq 5y agoI think \\?\ paths require backslashes.
- jaclaz 5y agoAlso, the Registry. And BTW .reg files need to double the backslash because it is parsed as an escape character.
- layer8 5y agoIt's required when passing a path as argument to Explorer. That is, when you type "explorer C:/" in the Run box or on the command line, Explorer opens in the default folder instead of in C:\. That's probably because Explorer also accepts URLs, so "explorer file://C:/" does work. For some reason, the Explorer address bar behaves differently.
- int_19h 5y agoAny / that occurs in an unquoted command line argument is going to be treated as a separator, so you've effectively invoked "explorer C: /".
- layer8 5y agoAnother difference from Unix is that Windows does not always normalize multiple consecutive backslashes or slashes to a single one. A path like "foo\\bar" (or "foo//bar") gets you "The file name is not valid" in File Open dialogs, for example.
- deleted 5y ago[deleted]
- tssva 5y agoThis isn't completely accurate. The Windows file dialog will not but the Win32 api does. Specifying a path such as foo\\bar in the shell for example will work. The exception is if the multiple slashes appear at the beginning of the path. Windows accepts UNC paths which begin with double slashes. It will not normalize multiple slashes into double slashes at the beginning of a path but any following multiple slashes will be normalized to a single slash.
- zelphirkalt 5y agoSome programming language(s?) seem to have taken over this strange characteristic: PHP. While most other languages use the backslash as an escaping symbol, in PHP you have it as a path separator in imports. It is not so nice.
- mattl 5y agoIsn't it used for namespacing in PHP?
- drekipus 5y agoI'd be hard pressed to find anything nice about PHP
- recursive 5y agoDeployment is easier than anything.
- pie_flavor 5y agoIf I throw a dart randomly at the Big Board O' Language Features: It is the only optionally typed language in common use whose types are checked at runtime. Or: Its type system has notation for 'the concrete type of `this`', what Rust calls `Self`, and no OO language in common use other than Swift has. It's actually pretty easy to find something nice about PHP.
- zelphirkalt 5y agoTypes being checked at runtime seems like a bad idea, because it wont help you discover mistakes before the program runs. Ideally it would check types before the program runs and give an option to have checks at runtime in parts, for when you cannot know at compile time. The type system also does apparently not provide a common Object kind of type. So Object cannot be used to work around the lack of generics. Making it difficult (impossible?) to create abstract data structures and making sure, that the functions for that ADT only accept things that adhere to some interface. This makes the type system rather less useful in general. I guess it all stems from the earlier days of PHP, where OOP was added badly and in hindsight. It still shows.
- adrian_b 5y agoThe article is slightly misleading about the usage of the forward slash in CP/M. It is true that the CP/M operating system itself did not use the forward slash, but the only reason for that was that the operating system included only a handful of executable programs, the main being the equivalents of the later "COMMAND.COM", "DEBUG.COM" and "COPY.COM" of Microsoft. The very few executable programs provided with the OS did not have any command-line options. A few of the most common file operations were shell built-ins, not separate executable programs. On the other hand, most CP/M executable programs (which were bought from third parties, not from Digital Research, the vendor of CP/M) had command-line options and, without exceptions, they used the forward slash for command-line options, instead of the hyphen used by UNIX. It would have been absolutely impossible to use CP/M without being aware of the convention that the forward slash is used for the command-line options. The article is completely correct that the use of the forward slash for options was not introduced by CP/M, but it was taken from the operating systems of the DEC Corp., which, during the seventies, were much more widely used than UNIX, which was an alternative for them only on PDP-11, and it was not yet used much outside the Bell Labs. Nevertheless, all the programs ported to MS-DOS 1.0 (e.g. MS BASIC, Turbo Pascal, WordStar, dBASE and so on) had not been ported from programs written for DEC OSes, but from programs written for CP/M. There is no doubt that the forward slash of MS-DOS 1.0 is directly inherited from CP/M. It was used by the same programs, for exactly the same options, so they must have kept the command-line parser without changes. I have used many of the same programs both first for CP/M and then for MS-DOS, so I can be certain about this. I have also used the DEC RSX-11M operating system on PDP-11, and indeed the RSX-11M utilities, for example PIP (Peripheral Interchange Program, a file transfer program with many options, somewhat like UNIX dd), used the forward slash many years before CP/M and most programmers for CP/M should have been familiar with this convention, so they have reused it, but the relationship from DEC OSes to MS-DOS 1.0 is indirect, via CP/M.
- pwdisswordfish9 5y agoThere is no COPY.COM.
- tasty_freeze 5y ago
- Maursault 5y ago> Both Windows 9x and NT were directly or indirectly derived from DOS and OS/2, False, or perhaps only true for "Windows NT" before Dave Cutler and his team developed it while working for Digital. After Cutler arrived at Microsoft and took over development of NT there (i.e. replaced it with the OS he developed at DEC at... not sure NT 4.x? ), Windows NT was no longer derived from DOS, rather, DOS was ported to Cutler's OS. The last OS derived from or based on DOS may have been Windows ME.
- voidfunc 5y agoYea Windows NT is really VMS evolved and there is the joke that WNT is VMS++.
- gatonegro 5y ago> The ergonomics of non-US keyboards were naturally not considered, which caused the path separator to be ridiculously difficult to type on some national keyboards (e.g. German), perhaps as a perverse reminder that ergonomics do matter. The more I've shifted towards a keyboard-centric workflow, the more I'm feeling this lack of consideration regarding non-US layouts. When using a Spanish keyboard, the placement of characters like forward slashes, backslashes, tildes, pipes, etc. can be physically painful after an extended typing session. I'm considering either getting a US keyboard, or doing some serious keyboard map tweaking. It's somewhat amusing to think that my current ergonomic predicaments are essentially the result of operating system and keyboard design choices and conventions that are over half a century old at this point.
- Nitrolo 5y agoI have a fairly keyboard centric workflow as well, and I didn't notice this until a few months ago I got a laptop with a US keyboard. Suddenly all those key bindings and symbols made sense, or at least were somewhat reachable without contorting my hands. I never noticed how terrible DE keyboards are for programming before but I don't want to go back.
- gsich 5y agoGerman backslash is very easy.
- int_19h 5y agoIt's one of the reasons why, if you ask programmers from other countries what they think about programming languages with "native" keywords, the response tends to be overwhelmingly negative. Code is particularly punctuation-heavy, especially with the modern trend of C-style syntax. US-English keyboard layout has all of the needed things readily accessible - of particular importance is that ".,;" all require a single keypress. But then you have to stick to ASCII for identifiers and keywords.
- erwincoumans 5y agoAside from the backslash history, Windows is very impressive in preserving backward compatibility. I still use a few programs over 20 years old (including JASC Paintshop Pro 7 from 2000, the 10 year old anniversary edition) and they still run on Windows 10.
- ahonhn 5y agoOh hey there. I'm still running Paint Shop Pro 8 which I purchased around 2002 or 2003 :-)
- HNHatesUsers 5y ago
- deleted 5y ago[deleted]
- SeanLuke 5y agoNext: a history of why HFS used colon as its separator.
- userbinator 5y agoThe author of this article tends to stay on the PC side, so I doubt he'll look into that. But others have written about it: https://retrocomputing.stackexchange.com/questions/17069/why-did-macos-classic-choose-the-colon-as-a-path-separator https://retrocomputing.stackexchange.com/questions/17069/why... Paths were, and to a certain extent still are, not readily visible on Macs.
- rswail 5y agoThe RT-11 OS for the DEC PDP used the forward slash for options and didn't have the concept of directories. The filename format for RT-11 was a three character device specifier, 6 character file name and 3 character extension CP/M borrowed most of its structure from RT-11 and also didn't have directories, just devices. The filename format was 8.3 instead of 6.3. MS-DOS in 2.0 (which introduced directories) defaulted to using the forward slash as the command options separator, but had an option in CONFIG.SYS for SWITCHAR that if you set to something other than forward slash, allowed you to use the forward slash as a directory separator.
- HdS84 5y agoAnd now most dev tools on windows have no problem to accept both slashes, but most Linux tools shit themselves when they see backslashes, different line endings or whitespace in paths. I am so annoyed by the Linux luddites.