8 ms·

Why does Windows use backslash as path separator? (2019)

72 points by lproven 3y ago

mholt 3y ago
I would just like to take this opportunity to complain about Windows file paths and especially parsing them in cross-platform software like a web server that joins request paths that always use / to Windows filepath roots that may or may not use \. I also hate that Windows paths are limited to 260 characters !? Seriously, in Caddy, I have some of the most bizarre special code paths for Windows. For example: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f46d03fd0fc5c233c686566f/modules/caddyhttp/matchers.go#L397-L404 https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4... Can someone who understands and appreciates the way Windows does files please help me appreciate it too? This article did not help me have gratitude for Windows: https://www.fileside.app/blog/2023-03-17_windows-file-paths/ https://www.fileside.app/blog/2023-03-17_windows-file-paths/ > we realise that we can construct an almost unlimited number of different path strings that all refer to the same directory. :o
- hgyjnbdet 3y ago
  > I also hate that Windows paths are limited to 260 characters !? Easily changed in the registry/ with group policy, though 256 should not be the default today.
  - mkoubaa 3y ago
    Can you assume your users do that?
    - smegsicle 3y ago
      if they installed windows they knew exactly what they were signing up for
  - jonathanlydall 3y ago
    Was going to say the situation with path lengths on Windows is mostly gone today, but it does still pop up on the odd occasion. For example the built in .zip file support can’t extract long paths (7-zip however has no issue). Also my Git client of choice (TortoiseGit) doesn’t fully handle long paths. But day to day long paths on Windows is fortunately not really an issue any more and they’ve been steadily improving support over the years. Despite generally being a fan of Windows, before Windows 10 the long path situation was infuriating, they even had a blog post acknowledging it’s a problem, but also stating it was going to be very non trivial to fix and as such they didn’t have any particular plans to fix it. I suspect that WSL made the limitation more regularly painful enough that they could convince managers that it’s something that had to get fixed. Windows Terminal was probably also motivated by WSL.
  - nullindividual 3y ago
    MAX_PATH used to be 260 characters but was changed fairly early in Windows 10 life to 32k. NTFS has always supported 32k characters in the path with each part being no more than 255 characters. Office, OTOH, does not respect/observe MAX_PATH. Do not exceed ~240 characters in the path + filename for an Office document as Office will be unable to open it.
- alkonaut 3y ago
  Coding with file system paths means accepting just a few difficult facts. - a path is not a unique identifier of a file system object. They don’t have canonical names. - don’t make any assumptions about case sensitivity, what file names are valid, or what the longest possible path is. - avoid baking paths from strings as as much as possible. Use constructs like PathBuf (Rust) that prevent footguns like duplicated or incorrect dir separators. Never use a literal path separator char ‘/‘ or ‘\’ in code is a good rule of thumb.
  - agumonkey 3y ago
    I remember one article about someone porting code from *nix to windows and having almost no issue due to the author leveraging pathlib. Just a side note.
    - Const-me 3y ago
      Same applies to C#. The standard library has pretty good APIs for dealing with file names and paths. In my experience, a program written in modern .NET 5+ and tested on Windows has a high probability to run flawlessly on Linux, without even a recompilation.
- deleted 3y ago
  [deleted]
- candiddevmike 3y ago
  Personally, I don't see the value in building server/tooling software for Windows these days. The market share just isn't there, and it ends up requiring a lot of work and testing to maintain.
  - Dalewyn 3y ago
    I would peruse such software. I can rely on Windows to still be running nice and happy a year later with no attention paid. I can rely on Linux to die to a stiff breeze. (Note: I'm probably cursed.)
    - lproven 3y ago
      It's odd. I often hear this, yet I have been professionally supporting Windows in production since version 2.01 in 1988, including deploying NT 3.1, in prod, before any service packs, in 1993. It is the direct opposite of 36 years of extensive professional experience. Linux is pretty tough. It will run on anything, and can cope with a lot of changes and damage. 21st century Windows is the most fragile OS I've worked with since classic MacOS.
- Atomskun 3y ago
  How in the world is your rant in linked file supposed to work? * It seems you decide whether to execute a file by its extension, e.g. `.php` * You are complaining that Windows is stripping away spaces, so `.php ` becomes `.php` * And supposedly this could lead the file being served as static text if you didn't have a Windows workaround? It rather seems to me that POSIX accepting `.php ` as a filename, and this not being picked up by a `.php` check is problematic here.
  - mholt 3y ago
    No, look at the associated unit test: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f46d03fd0fc5c233c686566f/modules/caddyhttp/matchers_test.go#L432-L449 https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4... If that test fails we could serve PHP source code instead of having it be evaluated, a potential security flaw.
- tredre3 3y ago
  The high level Win32 API does this to be helpful because a trailing space is usually not what the user wants. You can argue it's stupid if you want, but the OS supports files that end with dots and spaces just fine if you call the right APIs. I guess Go hooks into too high level of an API. But you can prefix all your paths with "\\?\" to "force it" to be evaluated as is. Consider the following program: package main import "os" func main() { os.Mkdir(os.Args[1], 0777) } Invoking test.exe c:\test... will create c:\test Invoking test.exe \\?\c:\test... will create c:\test... See: https://learn.microsoft.com/en-ca/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#win32-file-namespaces https://learn.microsoft.com/en-ca/windows/win32/fileio/namin... The link also explains why the file path length limit and details how to disable the limit.
NayamAmarshe 3y ago
Windows has caused us a lot of issues with Upscayl (https://upscayl.org https://upscayl.org). I personally do not use Windows but most of our errors are reported by Windows users where sometimes path parsing is a problem or the drivers mess up vulkan configuration. The fact that node takes a different approach to windows paths and sometimes the need to store these paths in storage and re-use them in external spawned processes makes it difficult to work with Windows' different and not so ideal path standards.
- harles 3y ago
  > Windows has caused us a lot of issues with Upscayl I’d turn that around. Sounds like Upscayl has caused a lot of issues for Windows users. Not developing on and doing little testing on Windows sure sounds like the problem to me.
  - indymike 3y ago
    First, I love Upscayl. Just used it to make about a decade of early lower resolution digital family photos 90s and early 00s printable and beautiful on HDPI screens. It's fantastic software. > Not developing on and doing little testing on Windows sure sounds like the problem to me. Most open source developers are not going to switch to "developing on" Windows because of posts like this. Nor should they. Upscayl is on GitHub and would probably appreciate some testing and fixing on Windows. As a developer, I don't use Windows at all. When I make cross platform software, dealing with MS-DOS anachronisms isn't interesting or fun. For paid work, yeah, OK I'll do it. But for free stuff, I can see where a developer might not want to put a lot of effort there and focus on the interesting part of their project.
    - Dalewyn 3y ago
      >But for free stuff, I can see where a developer might not want to put a lot of effort there and focus on the interesting part of their project. That's perfectly fine so long as one doesn't claim to be cross-platform (or supports Windows).
alkonaut 3y ago
> The path separator needed to be a key that does not require Shift to type Give these people a Nordic keyboard (it’s Alt+Gr plus one of the keys that is hardest to press while holding Alt+Gr).
- glandium 3y ago
  It's AltGr+8 on French keyboards. I think the backslash is not available without modifiers on most keyboard layouts, but US-centrism in decision making was strong back then.
  - Joe_Cool 3y ago
    I switched to EURKey since I figured I type code more than emails in languages that use umlauts or accents. It takes some getting used to (even more when coming from AZERTY) but it makes me so much more productive. No more cursing at CTRL+] hotkeys. It's included in most Linuxes and KDE and the homepage has a download for Windows and Mac as well as a nice keymap: https://eurkey.steffen.bruentjen.eu/ https://eurkey.steffen.bruentjen.eu/
  - euroderf 3y ago
    On Scando Mac it's Shift-Option-7. Gives new meaning to "three-fingered salute".
garciansmith 3y ago
I don't understand the last bit about the Model F Keyboard playing a role. Neither the slash nor backslash keys require shift to be pressed. Unless they just mean that the slash already had another role and therefore the only other free key was the backtick?
jtotheh 3y ago
I've seen some discussion of this, I believe that DOS got some ideas from a DEC OS (not VMS) that they were familiar with from using PDP-10s. Or something like that. Also, they had started using forward slashes to signify options to commands. Although I was a card-carrying Linux stan and Windows hater, starting with NT they have done a good job, overall. M$ makes backward compatibility a priority, and thus will not dump bad ideas that have become entrenched. I do think Jobs was right that M$ has "no taste". I am helping teach Intro to CS to HS students (ironically, through a M$ program) and even the teacher did not know why the C: drive is the letter that it is. AFAICT we're all condemned to live with choices made in a cheap clone of CP/M.... Of course other technologies have their bad choices as well (UNIX/C null-terminated strings, maybe, for instance?)
- bena 3y ago
  It's C: because A: and B: were already taken by your main drives, your floppy disks.
  - jtotheh 3y ago
    I know, but when did you last see a floppy disk?
    - bugfix 3y ago
      What would be the benefits of changing it now? Change for the sake of change would only break backwards compatibility.
      - jtotheh 3y ago
        UNIX etc has all file access start from /. DOS/Windows has separate trees starting with different letters. I think having it all in one tree structure has some advantages. All paths can be expressed as relative paths, for instance.
        wglb 3y ago
ape4 3y ago
One of the many problems is the need to escape it in C/C++ code - like LPSTR path = "C:\\Program Files"; They really should fix it. Better late than never.
- Tempest1981 3y ago
  Or use C++ raw string literals and experience inner peace: https://www.geeksforgeeks.org/raw-string-literal-c/ https://www.geeksforgeeks.org/raw-string-literal-c/
  - TillE 3y ago
    Or use fs::path with the / operator. If you're doing anything with file paths in C++, that class is a godsend. https://en.cppreference.com/w/cpp/filesystem/path https://en.cppreference.com/w/cpp/filesystem/path
    - paulmooreparks 3y ago
      Or just use '/' if you're talking directly to the API and not the shell or cmd.exe.
deleted 3y ago
[deleted]
PaulHoule 3y ago
It's a little known fact that most of Windows works just fine with "/" as a path separator, for instance if you make a system call to open a file or something. The major system that won't accept this is cmd.exe so if you are passing parameters to a .bat file that has a filename with a "/" in you will have trouble.
- coldpie 3y ago
  Yep. Drives me nuts when I see people fiddling with platform-specific path separators. Just use /, it works everywhere.
  - PaulHoule 3y ago
    I am really in the habit of using pathlib in Python and similar facilities in Java so I just write path = HOME / "cards" / f"{card_id}" / "card.yaml"
    - coldpie 3y ago
      You can do, or you can just skip all the spaces and extra quotes and junk and just use literal /. path = f"{HOME}/cards/{card_id}/card.yaml" Easier to read & write IMO, and works fine. Even on Windows.
      - skinner927 3y ago
        I really think they goofed Pathlib because of this. path = Path(“/foo”) / “a” / “b” / “c” The following is functionally equivalent to the above: path = Path(“/foo”) / “a/b/c” Which I really think was a mistake. The latter should resolve to “/foo/a\/b\/c” (IMO) because all other invalid characters (like space) are auto-escaped. What’s the point of the overloaded div operator otherwise?
        glandium 3y ago
        space is a valid character in paths. / is not. Never.
simonblack 3y ago
Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M FORMAT C: /S /U The option-indicator in UNIX-like systems was the dash/hyphen '-' ls -al
- Joe_Cool 3y ago
  thats why it also works without any spaces DIR C:/p/s/w Doesn't do what you might expect.
- glandium 3y ago
  And the article points out it's NOT a carry-over from CP/M.
  - dirkt 3y ago
    And I am not sure if their argument holds water. CP/M is clearly influenced by DEC usage [1], and various DEC OS and tools had slashes for tool options as a standard. Those then got carried over to CP/M (e.g. PIP), so that was the standard way to define options everyone CP/M used would have known. It's really really hard to imagine the usage for slashes as arguments was not a carry over. And for anyone old enough to actually remember the transition from CP/M to MS-DOS (like me), it felt very natural. [1] https://en.wikipedia.org/wiki/CP/M https://en.wikipedia.org/wiki/CP/M
    - fanf2 3y ago
      As the article explains, CP/M PIP uses [ ] for options, not /
- skissane 3y ago
  > Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M It wasn't a carry-over from CP/M itself. The utilities shipped with CP/M itself didn't use slash as an option character. PIP put options in square brackets. It was a carry-over from Microsoft's programming tools for CP/M. And, as the article points out, Microsoft appears to have borrowed that syntax from DEC TOPS-10, where it originated
zabzonk 3y ago
> “CP/M got the slash from VMS”, which is simply not possible because CP/M is older than VMS surely not - i used cp/m 1.x back in the late 1970s and by that time VMS was a well-developed and sophisticated OS, unlike cp/m which was something you could have knocked up in a week or so.
- InfamousRece 3y ago
  CP/M was released in 1974 while VMS was around 1977.
  - zabzonk 3y ago
    you are right. still, i don't think cp/m was used so much until the very late 70s, simply because microcomputers were not used so much until then. and at that time vms was far more powerful. i remember the first time i used vms compared with cp/m on a z80 - no contest.
    - lproven 3y ago
      > simply because microcomputers were not used so much until then Not really, no. It's not that they weren't used. It's that they didn't exist yet. The first 8-bit microprocessor, the Intel 8008, was 1972. The first chip for which CP/M was developed was the 8080 in 1974. It took a few years for mass availability. Given that you got your years badly wrong in your first comment, did you not think "hey I should check this" before commenting again?
- atombender 3y ago
  According to Wikipedia, CP/M was released in 1974, and VAX/VMS was "announced" in 1977 (presumably means it was available a bit later than that).
- ewgoforth 3y ago
  I always thought DOS got the backslash from VAX/VMS, a question which this article seems to avoid asking.
Alupis 3y ago
I find these sort of articles so very tiring... I realize this is from the OS/2 Museum and not Microsoft - but the result is the same: Article written about a poor engineering decision made decades ago, which for reasons that perplex everyone still live-on today. Then the Microsoft apologists come out of the woodwork to explain how easy it is to live with these poor engineering decisions and how smart Microsoft Engineers are, and how it's literally all other operating systems that somehow are lacking, blah blah blah. Backwards compatibility is usually the smoke screen apologists deploy during these discussions. As-if in the past few decades Microsoft couldn't have written a simple '\' -> '/' converter... Hell, if you look in the Explorer address bar, Microsoft even hides the path separator - opting to replace it with arrows instead. Let's not even start on the CRLF thing... Yes, Windows owes it's origin to OS/2, and OS/2 used '\' instead of '/' - so we should never correct a decision inherited from an OS that died 22 years ago...
- asveikau 3y ago
  With respect, what the hell are you talking about? Win32 file APIs can actually use either '/' or '\\' as a path separator. The stuff this is talking about is mostly around DOS command line tools and the successor, cmd.exe, which yes is mostly meant to run scripts written for DOS. '\\' was selected by DOS, specifically DOS 2.0 per TFA, several years before OS/2 existed.
  - Alupis 3y ago
    When you open Explorer and click in the address bar - what path separator is displayed? How about when you install software - what path separator does it show? > Win32 file APIs can actually use either '/' or '\\' as a path separator. Fantastic - so why are we still entertaining this idiotic file separator everywhere within the OS itself? > '\\' was selected by DOS, specifically DOS 2.0 per TFA, before OS/2 existed Fine - so why the hell are we still doing things like a dead, defunct OS did and literally nobody else did because, you know, it was unintelligent?
    - asveikau 3y ago
dunham 3y ago
The MSDOS 2.0 source code blames IBM: Most of these are due to last minute changes to achieve a greater degree of compatibility with IBM's implementation of MS-DOS (PC DOS). This includes the use of "\" instead of "/" as the path separator, and "/" instead of "-" as the switch character. https://github.com/microsoft/MS-DOS/blob/80ab2fddfdf30f09f0a0a637654cbb3cd5c7baa6/v2.0/bin/README.DOC#L43-L47 https://github.com/microsoft/MS-DOS/blob/80ab2fddfdf30f09f0a...
- jtotheh 3y ago
  MS-DOS didn't exist prior to PC-DOS, initially. "IBM's implementation of MS-DOS (PC DOS)" was the gold standard. all of it came from QDOS, a CP/M-like OS M$ bought based on hiding their plans, and that IBM made PC-DOS from. PC-DOS shipped with the original IBM PC. MS-DOS only became a thing once there were "IBM PC compatible" clones. It was very smart of M$ to see that coming. They kind of rode IBM's coattails into dominance in the market. Back then, personal computers were oddities and when IBM entered the game, their reputation gave them credibility.
  - skissane 3y ago
    > all of it came from QDOS I don't think 86-DOS (aka QDOS) itself had slash-based options. At least, in a quick skim of the 86-DOS 0.3 user manual I couldn't see any. [0] But they were there in PC-DOS 1.0, which suggests Microsoft added them after licensing 86-DOS. [0] https://web.archive.org/web/20160409042609/http://www.patersontech.com/dos/docs/86_Dos_usr_03.pdf https://web.archive.org/web/20160409042609/http://www.paters...

72 points by lproven 3y ago

I would just like to take this opportunity to complain about Windows file paths and especially parsing them in cross-platform software like a web server that joins request paths that always use / to Windows filepath roots that may or may not use \. I also hate that Windows paths are limited to 260 characters !? Seriously, in Caddy, I have some of the most bizarre special code paths for Windows. For example: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f46d03fd0fc5c233c686566f/modules/caddyhttp/matchers.go#L397-L404 https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4... Can someone who understands and appreciates the way Windows does files please help me appreciate it too? This article did not help me have gratitude for Windows: https://www.fileside.app/blog/2023-03-17_windows-file-paths/ https://www.fileside.app/blog/2023-03-17_windows-file-paths/ > we realise that we can construct an almost unlimited number of different path strings that all refer to the same directory. :o

hgyjnbdet 3y ago
> I also hate that Windows paths are limited to 260 characters !? Easily changed in the registry/ with group policy, though 256 should not be the default today.
- mkoubaa 3y ago
  Can you assume your users do that?
  - smegsicle 3y ago
    if they installed windows they knew exactly what they were signing up for
- jonathanlydall 3y ago
  Was going to say the situation with path lengths on Windows is mostly gone today, but it does still pop up on the odd occasion. For example the built in .zip file support can’t extract long paths (7-zip however has no issue). Also my Git client of choice (TortoiseGit) doesn’t fully handle long paths. But day to day long paths on Windows is fortunately not really an issue any more and they’ve been steadily improving support over the years. Despite generally being a fan of Windows, before Windows 10 the long path situation was infuriating, they even had a blog post acknowledging it’s a problem, but also stating it was going to be very non trivial to fix and as such they didn’t have any particular plans to fix it. I suspect that WSL made the limitation more regularly painful enough that they could convince managers that it’s something that had to get fixed. Windows Terminal was probably also motivated by WSL.
- nullindividual 3y ago
  MAX_PATH used to be 260 characters but was changed fairly early in Windows 10 life to 32k. NTFS has always supported 32k characters in the path with each part being no more than 255 characters. Office, OTOH, does not respect/observe MAX_PATH. Do not exceed ~240 characters in the path + filename for an Office document as Office will be unable to open it.
alkonaut 3y ago
Coding with file system paths means accepting just a few difficult facts. - a path is not a unique identifier of a file system object. They don’t have canonical names. - don’t make any assumptions about case sensitivity, what file names are valid, or what the longest possible path is. - avoid baking paths from strings as as much as possible. Use constructs like PathBuf (Rust) that prevent footguns like duplicated or incorrect dir separators. Never use a literal path separator char ‘/‘ or ‘\’ in code is a good rule of thumb.
- agumonkey 3y ago
  I remember one article about someone porting code from *nix to windows and having almost no issue due to the author leveraging pathlib. Just a side note.
  - Const-me 3y ago
    Same applies to C#. The standard library has pretty good APIs for dealing with file names and paths. In my experience, a program written in modern .NET 5+ and tested on Windows has a high probability to run flawlessly on Linux, without even a recompilation.
deleted 3y ago
[deleted]
candiddevmike 3y ago
Personally, I don't see the value in building server/tooling software for Windows these days. The market share just isn't there, and it ends up requiring a lot of work and testing to maintain.
- Dalewyn 3y ago
  I would peruse such software. I can rely on Windows to still be running nice and happy a year later with no attention paid. I can rely on Linux to die to a stiff breeze. (Note: I'm probably cursed.)
  - lproven 3y ago
    It's odd. I often hear this, yet I have been professionally supporting Windows in production since version 2.01 in 1988, including deploying NT 3.1, in prod, before any service packs, in 1993. It is the direct opposite of 36 years of extensive professional experience. Linux is pretty tough. It will run on anything, and can cope with a lot of changes and damage. 21st century Windows is the most fragile OS I've worked with since classic MacOS.
Atomskun 3y ago
How in the world is your rant in linked file supposed to work? * It seems you decide whether to execute a file by its extension, e.g. `.php` * You are complaining that Windows is stripping away spaces, so `.php ` becomes `.php` * And supposedly this could lead the file being served as static text if you didn't have a Windows workaround? It rather seems to me that POSIX accepting `.php ` as a filename, and this not being picked up by a `.php` check is problematic here.
- mholt 3y ago
  No, look at the associated unit test: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f46d03fd0fc5c233c686566f/modules/caddyhttp/matchers_test.go#L432-L449 https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4... If that test fails we could serve PHP source code instead of having it be evaluated, a potential security flaw.
tredre3 3y ago
The high level Win32 API does this to be helpful because a trailing space is usually not what the user wants. You can argue it's stupid if you want, but the OS supports files that end with dots and spaces just fine if you call the right APIs. I guess Go hooks into too high level of an API. But you can prefix all your paths with "\\?\" to "force it" to be evaluated as is. Consider the following program: package main import "os" func main() { os.Mkdir(os.Args[1], 0777) } Invoking test.exe c:\test... will create c:\test Invoking test.exe \\?\c:\test... will create c:\test... See: https://learn.microsoft.com/en-ca/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#win32-file-namespaces https://learn.microsoft.com/en-ca/windows/win32/fileio/namin... The link also explains why the file path length limit and details how to disable the limit.

NayamAmarshe 3y ago

Windows has caused us a lot of issues with Upscayl (https://upscayl.org https://upscayl.org). I personally do not use Windows but most of our errors are reported by Windows users where sometimes path parsing is a problem or the drivers mess up vulkan configuration. The fact that node takes a different approach to windows paths and sometimes the need to store these paths in storage and re-use them in external spawned processes makes it difficult to work with Windows' different and not so ideal path standards.

harles 3y ago
> Windows has caused us a lot of issues with Upscayl I’d turn that around. Sounds like Upscayl has caused a lot of issues for Windows users. Not developing on and doing little testing on Windows sure sounds like the problem to me.
- indymike 3y ago
  First, I love Upscayl. Just used it to make about a decade of early lower resolution digital family photos 90s and early 00s printable and beautiful on HDPI screens. It's fantastic software. > Not developing on and doing little testing on Windows sure sounds like the problem to me. Most open source developers are not going to switch to "developing on" Windows because of posts like this. Nor should they. Upscayl is on GitHub and would probably appreciate some testing and fixing on Windows. As a developer, I don't use Windows at all. When I make cross platform software, dealing with MS-DOS anachronisms isn't interesting or fun. For paid work, yeah, OK I'll do it. But for free stuff, I can see where a developer might not want to put a lot of effort there and focus on the interesting part of their project.
  - Dalewyn 3y ago
    >But for free stuff, I can see where a developer might not want to put a lot of effort there and focus on the interesting part of their project. That's perfectly fine so long as one doesn't claim to be cross-platform (or supports Windows).

alkonaut 3y ago

> The path separator needed to be a key that does not require Shift to type Give these people a Nordic keyboard (it’s Alt+Gr plus one of the keys that is hardest to press while holding Alt+Gr).

glandium 3y ago
It's AltGr+8 on French keyboards. I think the backslash is not available without modifiers on most keyboard layouts, but US-centrism in decision making was strong back then.
- Joe_Cool 3y ago
  I switched to EURKey since I figured I type code more than emails in languages that use umlauts or accents. It takes some getting used to (even more when coming from AZERTY) but it makes me so much more productive. No more cursing at CTRL+] hotkeys. It's included in most Linuxes and KDE and the homepage has a download for Windows and Mac as well as a nice keymap: https://eurkey.steffen.bruentjen.eu/ https://eurkey.steffen.bruentjen.eu/
- euroderf 3y ago
  On Scando Mac it's Shift-Option-7. Gives new meaning to "three-fingered salute".

garciansmith 3y ago

I don't understand the last bit about the Model F Keyboard playing a role. Neither the slash nor backslash keys require shift to be pressed. Unless they just mean that the slash already had another role and therefore the only other free key was the backtick?

jtotheh 3y ago

I've seen some discussion of this, I believe that DOS got some ideas from a DEC OS (not VMS) that they were familiar with from using PDP-10s. Or something like that. Also, they had started using forward slashes to signify options to commands. Although I was a card-carrying Linux stan and Windows hater, starting with NT they have done a good job, overall. M$ makes backward compatibility a priority, and thus will not dump bad ideas that have become entrenched. I do think Jobs was right that M$ has "no taste". I am helping teach Intro to CS to HS students (ironically, through a M$ program) and even the teacher did not know why the C: drive is the letter that it is. AFAICT we're all condemned to live with choices made in a cheap clone of CP/M.... Of course other technologies have their bad choices as well (UNIX/C null-terminated strings, maybe, for instance?)

bena 3y ago
It's C: because A: and B: were already taken by your main drives, your floppy disks.
- jtotheh 3y ago
  I know, but when did you last see a floppy disk?
  - bugfix 3y ago
    What would be the benefits of changing it now? Change for the sake of change would only break backwards compatibility.
    - jtotheh 3y ago
      UNIX etc has all file access start from /. DOS/Windows has separate trees starting with different letters. I think having it all in one tree structure has some advantages. All paths can be expressed as relative paths, for instance.
      - wglb 3y ago

ape4 3y ago

One of the many problems is the need to escape it in C/C++ code - like LPSTR path = "C:\\Program Files"; They really should fix it. Better late than never.

Tempest1981 3y ago
Or use C++ raw string literals and experience inner peace: https://www.geeksforgeeks.org/raw-string-literal-c/ https://www.geeksforgeeks.org/raw-string-literal-c/
- TillE 3y ago
  Or use fs::path with the / operator. If you're doing anything with file paths in C++, that class is a godsend. https://en.cppreference.com/w/cpp/filesystem/path https://en.cppreference.com/w/cpp/filesystem/path
  - paulmooreparks 3y ago
    Or just use '/' if you're talking directly to the API and not the shell or cmd.exe.

deleted 3y ago

[deleted]

PaulHoule 3y ago

It's a little known fact that most of Windows works just fine with "/" as a path separator, for instance if you make a system call to open a file or something. The major system that won't accept this is cmd.exe so if you are passing parameters to a .bat file that has a filename with a "/" in you will have trouble.

coldpie 3y ago
Yep. Drives me nuts when I see people fiddling with platform-specific path separators. Just use /, it works everywhere.
- PaulHoule 3y ago
  I am really in the habit of using pathlib in Python and similar facilities in Java so I just write path = HOME / "cards" / f"{card_id}" / "card.yaml"
  - coldpie 3y ago
    You can do, or you can just skip all the spaces and extra quotes and junk and just use literal /. path = f"{HOME}/cards/{card_id}/card.yaml" Easier to read & write IMO, and works fine. Even on Windows.
    - skinner927 3y ago
      I really think they goofed Pathlib because of this. path = Path(“/foo”) / “a” / “b” / “c” The following is functionally equivalent to the above: path = Path(“/foo”) / “a/b/c” Which I really think was a mistake. The latter should resolve to “/foo/a\/b\/c” (IMO) because all other invalid characters (like space) are auto-escaped. What’s the point of the overloaded div operator otherwise?
      - glandium 3y ago
        space is a valid character in paths. / is not. Never.

simonblack 3y ago

Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M FORMAT C: /S /U The option-indicator in UNIX-like systems was the dash/hyphen '-' ls -al

Joe_Cool 3y ago
thats why it also works without any spaces DIR C:/p/s/w Doesn't do what you might expect.
glandium 3y ago
And the article points out it's NOT a carry-over from CP/M.
- dirkt 3y ago
  And I am not sure if their argument holds water. CP/M is clearly influenced by DEC usage [1], and various DEC OS and tools had slashes for tool options as a standard. Those then got carried over to CP/M (e.g. PIP), so that was the standard way to define options everyone CP/M used would have known. It's really really hard to imagine the usage for slashes as arguments was not a carry over. And for anyone old enough to actually remember the transition from CP/M to MS-DOS (like me), it felt very natural. [1] https://en.wikipedia.org/wiki/CP/M https://en.wikipedia.org/wiki/CP/M
  - fanf2 3y ago
    As the article explains, CP/M PIP uses [ ] for options, not /
skissane 3y ago
> Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M It wasn't a carry-over from CP/M itself. The utilities shipped with CP/M itself didn't use slash as an option character. PIP put options in square brackets. It was a carry-over from Microsoft's programming tools for CP/M. And, as the article points out, Microsoft appears to have borrowed that syntax from DEC TOPS-10, where it originated

zabzonk 3y ago

> “CP/M got the slash from VMS”, which is simply not possible because CP/M is older than VMS surely not - i used cp/m 1.x back in the late 1970s and by that time VMS was a well-developed and sophisticated OS, unlike cp/m which was something you could have knocked up in a week or so.

InfamousRece 3y ago
CP/M was released in 1974 while VMS was around 1977.
- zabzonk 3y ago
  you are right. still, i don't think cp/m was used so much until the very late 70s, simply because microcomputers were not used so much until then. and at that time vms was far more powerful. i remember the first time i used vms compared with cp/m on a z80 - no contest.
  - lproven 3y ago
    > simply because microcomputers were not used so much until then Not really, no. It's not that they weren't used. It's that they didn't exist yet. The first 8-bit microprocessor, the Intel 8008, was 1972. The first chip for which CP/M was developed was the 8080 in 1974. It took a few years for mass availability. Given that you got your years badly wrong in your first comment, did you not think "hey I should check this" before commenting again?
atombender 3y ago
According to Wikipedia, CP/M was released in 1974, and VAX/VMS was "announced" in 1977 (presumably means it was available a bit later than that).
ewgoforth 3y ago
I always thought DOS got the backslash from VAX/VMS, a question which this article seems to avoid asking.

Alupis 3y ago

I find these sort of articles so very tiring... I realize this is from the OS/2 Museum and not Microsoft - but the result is the same: Article written about a poor engineering decision made decades ago, which for reasons that perplex everyone still live-on today. Then the Microsoft apologists come out of the woodwork to explain how easy it is to live with these poor engineering decisions and how smart Microsoft Engineers are, and how it's literally all other operating systems that somehow are lacking, blah blah blah. Backwards compatibility is usually the smoke screen apologists deploy during these discussions. As-if in the past few decades Microsoft couldn't have written a simple '\' -> '/' converter... Hell, if you look in the Explorer address bar, Microsoft even hides the path separator - opting to replace it with arrows instead. Let's not even start on the CRLF thing... Yes, Windows owes it's origin to OS/2, and OS/2 used '\' instead of '/' - so we should never correct a decision inherited from an OS that died 22 years ago...

asveikau 3y ago
With respect, what the hell are you talking about? Win32 file APIs can actually use either '/' or '\\' as a path separator. The stuff this is talking about is mostly around DOS command line tools and the successor, cmd.exe, which yes is mostly meant to run scripts written for DOS. '\\' was selected by DOS, specifically DOS 2.0 per TFA, several years before OS/2 existed.
- Alupis 3y ago
  When you open Explorer and click in the address bar - what path separator is displayed? How about when you install software - what path separator does it show? > Win32 file APIs can actually use either '/' or '\\' as a path separator. Fantastic - so why are we still entertaining this idiotic file separator everywhere within the OS itself? > '\\' was selected by DOS, specifically DOS 2.0 per TFA, before OS/2 existed Fine - so why the hell are we still doing things like a dead, defunct OS did and literally nobody else did because, you know, it was unintelligent?
  - asveikau 3y ago

dunham 3y ago

The MSDOS 2.0 source code blames IBM: Most of these are due to last minute changes to achieve a greater degree of compatibility with IBM's implementation of MS-DOS (PC DOS). This includes the use of "\" instead of "/" as the path separator, and "/" instead of "-" as the switch character. https://github.com/microsoft/MS-DOS/blob/80ab2fddfdf30f09f0a0a637654cbb3cd5c7baa6/v2.0/bin/README.DOC#L43-L47 https://github.com/microsoft/MS-DOS/blob/80ab2fddfdf30f09f0a...

jtotheh 3y ago
MS-DOS didn't exist prior to PC-DOS, initially. "IBM's implementation of MS-DOS (PC DOS)" was the gold standard. all of it came from QDOS, a CP/M-like OS M$ bought based on hiding their plans, and that IBM made PC-DOS from. PC-DOS shipped with the original IBM PC. MS-DOS only became a thing once there were "IBM PC compatible" clones. It was very smart of M$ to see that coming. They kind of rode IBM's coattails into dominance in the market. Back then, personal computers were oddities and when IBM entered the game, their reputation gave them credibility.
- skissane 3y ago
  > all of it came from QDOS I don't think 86-DOS (aka QDOS) itself had slash-based options. At least, in a quick skim of the 86-DOS 0.3 user manual I couldn't see any. [0] But they were there in PC-DOS 1.0, which suggests Microsoft added them after licensing 86-DOS. [0] https://web.archive.org/web/20160409042609/http://www.patersontech.com/dos/docs/86_Dos_usr_03.pdf https://web.archive.org/web/20160409042609/http://www.paters...