[HN Gopher] Why does Windows use backslash as path separator? (2...
___________________________________________________________________
Why does Windows use backslash as path separator? (2019)
Author : lproven
Score : 52 points
Date : 2024-04-24 19:52 UTC (3 hours ago)
(HTM) web link (www.os2museum.com)
(TXT) w3m dump (www.os2museum.com)
| mholt wrote:
| 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/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/
|
| _> we realise that we can construct an almost unlimited number
| of different path strings that all refer to the same directory._
|
| :o
| hgyjnbdet wrote:
| > 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 wrote:
| Can you assume your users do that?
| jonathanlydall wrote:
| 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.
| alkonaut wrote:
| 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 wrote:
| 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.
| candiddevmike wrote:
| 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.
| Atomskun wrote:
| 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 wrote:
| No, look at the associated unit test: https://github.com/cadd
| yserver/caddy/blob/c6eb186064091c79f4...
|
| If that test fails we could serve PHP source code instead of
| having it be evaluated, a potential security flaw.
| tredre3 wrote:
| 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/namin...
|
| The link also explains why the file path length limit and
| details how to disable the limit.
| NayamAmarshe wrote:
| Windows has caused us a lot of issues with Upscayl
| (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 wrote:
| > 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.
| jonathanlydall wrote:
| Our desktop product built using Electron and .NET runs cross
| platform.
|
| Originally it was on Windows only and I personally did the work
| required to make it work cross platform once .NET Core became
| mature enough, so I'm very familiar with the path separator
| challenges.
|
| It was a bit of a pain, but not a huge deal. The trick was to
| just use forward slashes all the time, except for display or
| storing an absolute path.
|
| Windows doesn't seem to care when you use forward slashes for
| everything even if looks wrong.
|
| Admittedly the Node code dealing with paths is limited as most
| of the heavy work in our app is done in a .NET background
| agent, but there are things like file selection dialogues and
| config loading that is in the Node part.
|
| Based on the fact I can't remember exactly what I did for paths
| in Node leads me to believe it was pretty much a non-issue, I
| probably used forward slashes and it just worked.
|
| It took a lot more work for the .NET aspect where we're doing a
| lot more stuff on the file system, I had to find and replace
| most path usages with a utility function to convert the
| separators appropriately.
| alkonaut wrote:
| > 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 wrote:
| 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 wrote:
| 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/
| garciansmith wrote:
| 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 wrote:
| 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 wrote:
| It's C: because A: and B: were already taken by your _main_
| drives, your floppy disks.
| jtotheh wrote:
| I know, but when did you last see a floppy disk?
| bugfix wrote:
| What would be the benefits of changing it now? Change for
| the sake of change would only break backwards
| compatibility.
| jtotheh wrote:
| 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.
| tredre3 wrote:
| You can set your main drive to the letter A or B, if it
| truly bothers you.
| doublepg23 wrote:
| I'd be all for a GoboLinux revolution but it seems unlikely
| from a "if it ain't broke..." POV.
| pixelesque wrote:
| The article mentions your first few sentences...
|
| In the early DOS days, you didn't always have hard drives, but
| you'd always have floppy disks to boot from, and those letters
| were used first alphabetically.
| ape4 wrote:
| 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 wrote:
| Or use C++ raw string literals and experience inner peace:
|
| https://www.geeksforgeeks.org/raw-string-literal-c/
| TillE wrote:
| 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
| PaulHoule wrote:
| 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 wrote:
| Yep. Drives me nuts when I see people fiddling with platform-
| specific path separators. Just use /, it works everywhere.
| PaulHoule wrote:
| 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 wrote:
| 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 wrote:
| 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?
| Zamicol wrote:
| It's been years since I've had to work on a Windows system,
| but I'm suspicious of that. Days of my career at the State of
| Colorado has been spent fixing / problems. Is this something
| on newer Windows systems?
| coldpie wrote:
| If you're mucking around with legacy parts of the OS, you
| might run into troubles. But if you're just doing regular
| old file I/O from a normal program, nah. Windows doesn't
| care. You can even mix them.
| simonblack wrote:
| 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 wrote:
| thats why it also works without any spaces DIR
| C:/p/s/w
|
| Doesn't do what you might expect.
| zabzonk wrote:
| > "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 wrote:
| CP/M was released in 1974 while VMS was around 1977.
| zabzonk wrote:
| 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.
| atombender wrote:
| 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).
| Alupis wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > Fantastic - so why are we still entertaining this idiotic
| file separator everywhere within the OS itself?
|
| Dude, why are you so angry about what direction a slash
| goes?
|
| Once they introduced the ability to use either one, they
| still had a lot of software that hardcoded '\\\', including
| lots of their own. Again, they support either one in most
| places. The backslash is considered more canonical because
| it came first.
|
| Going back to DOS for a second, TFA even says Microsoft
| wanted to use '/' in DOS 2.0 when they introduced
| directories (1983), but IBM objected.
| Alupis wrote:
| IBM objected in 1983 - yet that decision lives on today?
| It's what Windows displays to users, even if you can
| actually type in / and things still work.
|
| When Microsoft wrote IIS and other web technologies the
| internal friction of path separators must have been fun
| to experience. "Why are we still using \ again, Jim? Oh,
| that's right, we chose poorly a decade ago and for some
| reason can't be bothered to fix it!"
|
| > Dude, why are you so angry about what direction a slash
| goes?
|
| Because it's rubbed my bum raw over the years and I've
| finally had enough! I mostly jest... but seriously, it's
| super annoying to deal with and a constant reminder of
| the poor decision making Microsoft products often
| encompass.
| foobarian wrote:
| You know what happens when you write a \ --> / converter?
| You get the python2 to python3 migration mess. Except
| with Windows it would have been millions of mom and pop
| shops left out in the lurch.
| Alupis wrote:
| No it wouldn't - because Microsoft did write a \ -> /
| converter and none of this bad stuff happened.
|
| Microsoft just _chooses_ to still display \ to you in the
| UI... which is ridiculous and perpetuates \ living on in
| all user-facing places.
| nullindividual wrote:
| Microsoft was very smart to use the backslash. It lead to
| unrivaled backwards compatibility.
|
| Saying it was the wrong choice is simply revisionist
| history.
| Alupis wrote:
| So, we would lose all backwards compatibility by writing
| a \ -> / converter? I don't buy this logic at all - in
| fact, as others have pointed out, Windows will accept
| both separators these days.
|
| You are, unintentionally, being the very sort of
| apologist my post above complained about.
| naikrovek wrote:
| I think you just need to get over whatever is making you
| angry. Non-POSIX systems exist, dude. It's ok for things
| to exist...
| asveikau wrote:
| Tempted to bring in the fact that classic Mac used colons
| as a path separator.
|
| As TFA says it wasn't clear yet that unix would be so
| dominant. Also, a lot of these systems were introducing
| the concept of directories for the first time in their
| history. That's how old we're talking. That directories
| are novel to some people at that point.
| Capricorn2481 wrote:
| > 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?
|
| Nobody is doing it except the people using cmd.exe over
| Windows Terminal or Powershell. If you're using a DOS
| terminal you're gonna get DOS results.
| itslennysfault wrote:
| As a long time *nix user who briefly worked at Microsoft (and
| therefore on Windows), I was very happy to learn that
| Powershell is perfectly happy with forward slashes in paths. If
| you tab-complete it switches them to backslashes (which is
| "fine"), but you can type commands using forward slashes
| without issue. Also common linux commands (ls, cd, mv, cp) all
| work in Powershell. It really makes the transition painless.
| Alupis wrote:
| I personally have found PowerShell to be obnoxious. It
| doesn't seem to know what it's supposed to be and tries to be
| everything all at once. The syntax for commands is super
| "Microsofty" if you know what I mean.
|
| I get around by using Git Bash (which is actually quite good
| for being a bundled afterthought), cygwin, or lately even WSL
| containers.
| sbelskie wrote:
| What different things do you think it is trying to be?
| therein wrote:
| I have nothing against PowerShell. I've used it for
| avoiding detection etc. in the past. Fun tool that
| surprises and delights in unexpected ways.
|
| It is pretty powerful/insane that stuff like this is a
| part of PowerShell and that's probably what the GP is
| talking about: Add-Type -TypeDefinition
| @" using System; namespace DemoCode
| { public class DemoClass {
| public static void WriteHello() {
| Console.WriteLine("Hello"); }
| } } "@
| [DemoCode.DemoClass]::WriteHello()
|
| Or LoadLibrary call and invocation from PowerShell. [0]
| [1]
|
| It blurs the lines as to what it is no matter how you
| look at it.
|
| In contrast, try doing that in cmd.exe or invoking a
| function from a shared object after getting a pointer to
| it using dlopen through a POSIX shell.
|
| [0] -
| https://www.powershellgallery.com/packages/PSReflect-
| Functio...
|
| [1] - https://fuzzysecurity.com/tutorials/24.html
| Nihilartikel wrote:
| I work a lot in powershell, and I want to like it. It is
| built around good ideas.. but oof, every time I have to
| special case on a return value being either a list or a
| single item depending on the result-len==1 or not, I die a
| little inside.
| ScottEvtuch wrote:
| I think there are some tricks to ensure a list in pwsh for
| these sort of operations. I vaguely recall ending variable
| assignments with a comma to avoid this.
| jiggawatts wrote:
| $alwaysList = @( Get-Something )
| naikrovek wrote:
| Windows itself is fine with forward slashes as a path
| separator, as well, though LOTS of userland Windows
| applications weren't aware of this and enforced backslashes
| themselves.
|
| Command lines, graphical shells, OS save and open file
| dialogs do not care if you use slash or backslash, and the
| Win32 API has never enforced backslashes as a path separator.
| mardifoufs wrote:
| Why is / better than \ ?
| OsrsNeedsf2P wrote:
| Apart from the fact \ is used as an escape sequence?
| Alupis wrote:
| For starters, `\\` is used for escape sequences for just
| about everything... meaning you now have to do the `\\\\`
| dance everywhere you need to write this path separator.
|
| Yes, it's true modern languages have things like
| `Path.separator` and stuff to abstract this away, but you
| cannot always use them in all contexts.
|
| It's small friction that adds up to a sore bum after a
| while...
| Joe_Cool wrote:
| The real fun starts with UNC paths. Is it
| `\\\\\\\server\\\share\ with\ space` or `//server/share\
| with\ space` or any combination of those, preferably with
| quotes.
| dekhn wrote:
| I use forward and backward slash on Windows all the time. I
| think it's less of a problem of spaces in filenames, which
| makes a lot of pipe-related stuff harder to do (see find
| -print0 and xargs -0).
| asveikau wrote:
| Spaces in filenames in the command line on Windows is a
| horror in part because there is no kernel level equivalent of
| argv. In the eyes of the Windows kernel, the command line is
| an unparsed utf-16 string, and it's up to the application or
| C library to tokenize it. This means there is no standard way
| to tokenize it. Ultimately, this means there is no standard
| way to escape a shell command's arguments, as you would need
| to do for spaces. Most people just put it in double quotes
| but this is pretty much the honor system.
| jiggawatts wrote:
| Just use PowerShell. It has no issues with spaces anywhere,
| and uses explicit quoting rules similar to C# and other
| "proper" languages.
| asveikau wrote:
| If powershell is dispatching to other cmdlets then fine.
| If it needs to call CreateProcess on a win32 program then
| the issue I'm talking about definitely exists.
|
| (I don't personally like powershell but I don't think my
| gripes with it are really relevant to this thread.)
| hun3 wrote:
| [delayed]
| canucker2016 wrote:
| Windows used many of the MSDOS services, like file system
| access. Windows was built on top of MSDOS in the beginning.
|
| Windows predates OS/2 (OS/2 development started in 1985
| according to Wikipedia)
|
| How is it a poor engineering decision?
|
| What about the original Mac OS using colon as a path separator?
| Or Lisa OS using the hyphen as a path separator?
|
| see
| https://retrocomputing.stackexchange.com/questions/17069/why...
| TillE wrote:
| Yeah I think it's far more interesting to view this as a
| series of people making probably the best possible decision
| at the time, and winding up in a slightly unfortunate,
| suboptimal place.
|
| That's hardly uncommon! Examine the history of basically
| anything.
| naikrovek wrote:
| > Microsoft reportedly wanted to use the forward slash as
| path separator, but IBM nixed the idea because it would have
| created an incompatibility with DOS 1.x, which already used
| the forward slash as a switch character, separating command
| options.
|
| It isn't a poor engineering decision, that guy just didn't
| read the decision criteria.
|
| Also, according to spec, CRLF is the proper sequence for a
| newline, and both Unix and MacOS chose incorrectly.
| Alupis wrote:
| Which spec would that be? It's not the ISO spec, nor POSIX.
|
| CRLF existed originally because of mechanical typerwriters
| required two separate actions - Carriage Return (move the
| carriage back to the start of the line), Line Feed (advance
| the page to the next line).
|
| CR is a waste for computing... it literally does nothing
| beneficial.
|
| Someone should figure out the climate impact of decades of
| wasted processing of CR characters... that might motivate
| people to fix this as well.
| Joe_Cool wrote:
| Japanese DOS had Y= as the path separator or more specific at
| 0x5C. It still causes headache with the MS Mincho font.
| Japanese users are used to seeing Y= at the DOS prompt so
| some Windows Console fonts just replace the backslash.
|
| Since you never know if it's a backslash or an actual Yen
| sign. Total fun.
| naikrovek wrote:
| Windows existed before OS/2, though, and MS-DOS (where Windows'
| path separator comes from) is of course even older.
|
| It's ok to hate Microsoft, but hate them based on facts, and
| not whatever nonsense you have in mind.
| dunham wrote:
| 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/80ab2fddfdf30f09f0a...
| jtotheh wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-24 23:01 UTC)