9 ms·

Backslash must die

157 points by chris-at 11y ago

mikestew 11y ago
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 11y ago
  And the path length limitation
  - guy1543 11y ago
    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.
    - sebtoast 11y ago
      I just tried and it works in Windows... I didn't know that despite using cmd/powershell everyday.
    - Mithaldu 11y ago
      Depends on what you're doing. `dir relative/path` does not work.
    - chris-at 11y ago
      Did you try it on Windows 10? If I try to open a file `i:/foo/bar/test.txt` I get `The file name is not valid` (from Notepad)
      - kej 11y ago
        I just did exactly that on Windows 10 and it worked just fine.
        sp332 11y ago
        It didn't work for me either.. huh.
        kej 11y ago
        We're trying different things, I think. I was doing notepad i:/whatever on the command line and you're using the file open dialog within notepad, which doesn't work. Sorry for the confusion.
    - hackuser 11y ago
      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-windows-start-accepting-forward-slash-path-separator https://bytes.com/topic/python/answers/23123-when-did-window... [2] https://stackoverflow.com/questions/10523708/why-does-the-cmd-exe-shell-on-windows-fail-with-paths-using-a-forward-slash https://stackoverflow.com/questions/10523708/why-does-the-cm... [3] https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-is-the-dos-path-character/ https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...
      - pwg 11y ago
        > 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/why-is-the-dos-path-character/ https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh... [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]
    - sixothree 11y ago
      Unfortunately it does not work when specifying a server name like \\server1.
  - mikestew 11y ago
    (Three levels of comments, and one can no longer reply? Sorry, throweway, I have to hijack your comment to reply to guy1543.) Guy1543, thanks, I did not know that. And I wish I had known it sooner. :-)
    - teh_klev 11y ago
      Click on (or open in a new tab) the comment timestamp link of the comment you wish to reply to and you'll see the reply link. I think HN stops showing the reply link after three levels into a thread to discourage possible flamewars/threads going off the reservation
      - skykooler 11y ago
        Interestingly, your post showed a reply link for me.
        rcthompson 11y ago
        I think the reply links on rapidly-growing threads are hidden temporarily as a rate-limiting mechanism.
  - maxxxxx 11y ago
    Yes, that needs to go. We are spending tons of time making file names arbitrarily shorter to stay under 255 characters.
    - labster 11y ago
      Right. Who wants to use a platform where you can't base64 the file's data into the filename?
      - teddyh 11y ago
        Not the base file name, the entire path to the file must be 255 characters or less.
        labster 11y ago
        Really? That sounds like a huge PITA. And here I've been complaining about HFS+ all this time, but the OS X APIs are better than that.
        wolfgke 11y ago
        Not true: They must be less than 2^15 characters long. If you use the standard file APIs on Windows (most applications do) there exists a limit of 260 characters for the path. To access longer paths you have to use the Shell API (only few applications do): > http://stackoverflow.com/a/31142839/497193 http://stackoverflow.com/a/31142839/497193
        ygra 11y ago
        Uhm, Shell APIs are necessary when you're dealing with shell objects, but all filesystem APIs can work with paths longer than MAX_PATH iff you use the Unicode API (e.g. CreateFileW) and prefix the path with \\?\ [½]. They can't retroactively change MAX_PATH because it's a constant that's compiled in every application that uses it. Well-written applications these days will just do the \\?\ thing and be done with it. The downside of that is that you can get paths Explorer doesn't like. And I'm guessing Explorer explicitly doesn't allow you to create paths longer than MAX_PATH to prevent people complaining about »I created a folder in Explorer and copied a file there, but now I cannot open it.«. Keep in mind that (usually) developers can be expected to find solutions, but making it easy to frustrate regular users (of which the OS has at least a few hundred million) is not the best strategy to keep them using the OS. Of course, there are also heaps of software that cannot use above method to allow for longer paths because they don't use the Unicode APIs. Maybe because some developers think supporting Windows 98 is a good idea nowadays, or because they just don't know any better. And in that heap there's a lot of poorly-ported open-source software, too. [½] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
  - peelingoranges 11y ago
    Path length limit is 32767 characters, do you need more? See: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
    - techthroway443 11y ago
      From the first sentence of the page you linked to: > In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. Reading comprehension, do you need more?
      - deleted 11y ago
        [deleted]
      - tremon 11y ago
        Yes, I need more. Is that defined as 260 bytes or 260 characters? The following paragraphs do mention Unicode normalization and storage (USC-2 probably, given Microsoft's penchant for backwards compatibility), but not how that affects the path length. Are combining characters counted separately for MAX_PATH purposes? Do surrogate pairs count as one or two characters? This is 2016, we really shouldn't need to be asking these byte-vs-character questions any more :(
        techthroway443 11y ago
        > Is that defined as 260 bytes or 260 characters? > MAX_PATH, which is defined as 260 characters. bruh
      - saulr 11y ago
        Continuing to read the exceptions: > The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
  - tobias3 11y ago
    In the Win32 API you can either have * Forward slashes in paths but only 260 characters as max path length * Maximum total path length of 32,767 characters but not forward slashes as path separator Pick your poison.
deleted 11y ago
[deleted]
monochromatic 11y ago
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 11y ago
  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 11y ago
    It doesn't help that the various Windows dialogues treat '/' differently. Windows really should have just one file open dialogue, etc.
    - wlesieutre 11y ago
      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.
Animats 11y ago
And, after that, kill CR LF as a line separator. That's an idea which belongs to the era of mechanical Teletype machines.
- nivla 11y ago
  Ya that I too agree with this, pretty much all applications can now deal with \n just fine. Having CR LF (2 Bytes) is not only wasting storage space but also wasting bandwidth when transmitting. While at it, I also wish if Linux distros could get done with case sensitiveness in filenames. Is there any advantage to allowing both Filename.ext and filename.ext? The only time I seen this is when a malware is trying to stay hidden. Also some naming conventions would be nice, when you can have any character including '/' and '.' as a filename, it gets annoying to deal with them in a cli.
  - jonathankoren 11y ago
    > Is there any advantage to allowing both Filename.ext and filename.ext? Sorting by ascii order put capitalized files to the top of the list. Exactly where you should look for important stuff like README and Makefile. Case preservation without case sensitivity is just dumb. Why bother, because it's pretty? Also, what's up with spaces in filenames? And furthermore, what are all these kids doing on my lawn?
    - wlesieutre 11y ago
      > Also, what's up with spaces in filenames? What's_up_with_spaces_at_all? Let's_just_join_sentences_with_underscores_for_clarity.
      - cmdrfred 11y ago
        iPreferCamelCase
        5ilv3r 11y ago
        kebab-case-is-better
_kst_ 11y ago
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 11y ago
  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 11y ago
    Either your system font is weird, or you're dyslectic. Seriously.
    - sp332 11y ago
      *dyslexic
- sixothree 11y ago
  Akthough this does work dir "c:/*.txt" /w/o/s/p
- epsylon 11y ago
  Not really a problem since a path never starts with a / in a Windows environment.
  - jjnoakes 11y ago
    If one used / as a path separator, then yes, a path could indeed start with / and be confused with options.
- JdeBP 11y ago
  A simpler example is cd\windows I explicitly and deliberately differed from this when I wrote a command interpreter. * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/cmd/guide/differences.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
skrebbel 11y ago
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 11y ago
  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 11y ago
    Probably no source other than: there are 1B+ Windows users (like me) vs. maybe 100M Mac users + a few million Unix-y users.
    - jdietrich 11y ago
jonathankoren 11y ago
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 11y ago
Would that involve also adding smb://HOSTNAME as opposed to \\HOSTNAME?
- hug 11y ago
  PS C:\> cd ~/.. PS C:\Users> cd / PS C:\> cd //localhost/c$ PS Microsoft.PowerShell.Core\FileSystem::\\localhost\c$>
- rcarmo 11y ago
  That is how things work on a Mac.
jasonjei 11y ago
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.
- iokanuon 11y ago
  Just set up a few symlinks ln -s /mnt/c/Users /home ln -s '/mnt/c/Program Files' /opt ...
- wolfgke 11y ago
  > 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 Windows does internally - even in a network-transparent way: https://en.wikipedia.org/w/index.php?title=Path_(computing)&oldid=703365694#Uniform_Naming_Convention https://en.wikipedia.org/w/index.php?title=Path_(computing)&...
- Arnavion 11y ago
  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.
- daurnimator 11y ago
  > Windows a first-class POSIX development setup. http://midipix.org/ http://midipix.org/ Coming soon :)
skywhopper 11y ago
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.
glandium 11y ago
The best part of using backslashes in paths is that for character encoding historical reasons, backslashes are printed as ¥ in Japan. C:¥Windows¥System32.
TazeTSchnitzel 11y ago
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 11y ago
  A more detailed representation of this topic: http://www.howtogeek.com/181774/why-windows-uses-backslashes-and-everything-else-uses-forward-slashes/ http://www.howtogeek.com/181774/why-windows-uses-backslashes... 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=680322555 https://en.wikipedia.org/w/index.php?title=Files-11&oldid=68...)
  - zippergz 11y ago
    I used VMS for a while (I never became a power user), and it always felt really weird to me. But I'm not sure if it actually IS weird, or if it just seemed that way because I was already so familiar with Unix. On the one hand, directory separation characters are kind of arbitrary. But my brain insists that "/" is more natural than . (or ":" on MacOS).
    - bbatha 11y ago
      Well VMS also had this nonsense for fully qualified paths, NODE"accountname password"::device:[directory.subdirectory]filename.type;ver everything except filename.type is optional based on the users current DEFAULT (pwd in unix parlance). And required extensions and used the "." separator making it overloaded and confusing to read at a glance. Edit: forgot a few parts of the qualified path.
gozur88 11y ago
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 11y ago
  That was intentional to force programs to work with spaces and "special" characters.
  - gozur88 11y ago
    If so, that's pretty short-sighted. It's almost impossible to type them out.
  - tdeck 11y ago
    Do you have a source for this? It sounds interesting, but also like an urban legend.
  - Stratoscope 11y ago
    Naw, it was just to give users "friendlier" directory names like "Program Files" and "Documents and Settings".
dandare 11y ago
Why is backslash called BACK slash when it actually points forward? http://ux.stackexchange.com/questions/92390/why-is-backslash-called-back-slash-when-it-actually-points-forward http://ux.stackexchange.com/questions/92390/why-is-backslash...

157 points by chris-at 11y ago

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 11y ago
And the path length limitation
- guy1543 11y ago
  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.
  - sebtoast 11y ago
    I just tried and it works in Windows... I didn't know that despite using cmd/powershell everyday.
  - Mithaldu 11y ago
    Depends on what you're doing. `dir relative/path` does not work.
  - chris-at 11y ago
    Did you try it on Windows 10? If I try to open a file `i:/foo/bar/test.txt` I get `The file name is not valid` (from Notepad)
    - kej 11y ago
      I just did exactly that on Windows 10 and it worked just fine.
      - sp332 11y ago
        It didn't work for me either.. huh.
        kej 11y ago
        We're trying different things, I think. I was doing notepad i:/whatever on the command line and you're using the file open dialog within notepad, which doesn't work. Sorry for the confusion.
  - hackuser 11y ago
    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-windows-start-accepting-forward-slash-path-separator https://bytes.com/topic/python/answers/23123-when-did-window... [2] https://stackoverflow.com/questions/10523708/why-does-the-cmd-exe-shell-on-windows-fail-with-paths-using-a-forward-slash https://stackoverflow.com/questions/10523708/why-does-the-cm... [3] https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-is-the-dos-path-character/ https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...
    - pwg 11y ago
      > 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/why-is-the-dos-path-character/ https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh... [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]
  - sixothree 11y ago
    Unfortunately it does not work when specifying a server name like \\server1.
- mikestew 11y ago
  (Three levels of comments, and one can no longer reply? Sorry, throweway, I have to hijack your comment to reply to guy1543.) Guy1543, thanks, I did not know that. And I wish I had known it sooner. :-)
  - teh_klev 11y ago
    Click on (or open in a new tab) the comment timestamp link of the comment you wish to reply to and you'll see the reply link. I think HN stops showing the reply link after three levels into a thread to discourage possible flamewars/threads going off the reservation
    - skykooler 11y ago
      Interestingly, your post showed a reply link for me.
      - rcthompson 11y ago
        I think the reply links on rapidly-growing threads are hidden temporarily as a rate-limiting mechanism.
- maxxxxx 11y ago
  Yes, that needs to go. We are spending tons of time making file names arbitrarily shorter to stay under 255 characters.
  - labster 11y ago
    Right. Who wants to use a platform where you can't base64 the file's data into the filename?
    - teddyh 11y ago
      Not the base file name, the entire path to the file must be 255 characters or less.
      - labster 11y ago
        Really? That sounds like a huge PITA. And here I've been complaining about HFS+ all this time, but the OS X APIs are better than that.
      - wolfgke 11y ago
        Not true: They must be less than 2^15 characters long. If you use the standard file APIs on Windows (most applications do) there exists a limit of 260 characters for the path. To access longer paths you have to use the Shell API (only few applications do): > http://stackoverflow.com/a/31142839/497193 http://stackoverflow.com/a/31142839/497193
        ygra 11y ago
        Uhm, Shell APIs are necessary when you're dealing with shell objects, but all filesystem APIs can work with paths longer than MAX_PATH iff you use the Unicode API (e.g. CreateFileW) and prefix the path with \\?\ [½]. They can't retroactively change MAX_PATH because it's a constant that's compiled in every application that uses it. Well-written applications these days will just do the \\?\ thing and be done with it. The downside of that is that you can get paths Explorer doesn't like. And I'm guessing Explorer explicitly doesn't allow you to create paths longer than MAX_PATH to prevent people complaining about »I created a folder in Explorer and copied a file there, but now I cannot open it.«. Keep in mind that (usually) developers can be expected to find solutions, but making it easy to frustrate regular users (of which the OS has at least a few hundred million) is not the best strategy to keep them using the OS. Of course, there are also heaps of software that cannot use above method to allow for longer paths because they don't use the Unicode APIs. Maybe because some developers think supporting Windows 98 is a good idea nowadays, or because they just don't know any better. And in that heap there's a lot of poorly-ported open-source software, too. [½] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
- peelingoranges 11y ago
  Path length limit is 32767 characters, do you need more? See: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
  - techthroway443 11y ago
    From the first sentence of the page you linked to: > In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. Reading comprehension, do you need more?
    - deleted 11y ago
      [deleted]
    - tremon 11y ago
      Yes, I need more. Is that defined as 260 bytes or 260 characters? The following paragraphs do mention Unicode normalization and storage (USC-2 probably, given Microsoft's penchant for backwards compatibility), but not how that affects the path length. Are combining characters counted separately for MAX_PATH purposes? Do surrogate pairs count as one or two characters? This is 2016, we really shouldn't need to be asking these byte-vs-character questions any more :(
      - techthroway443 11y ago
        > Is that defined as 260 bytes or 260 characters? > MAX_PATH, which is defined as 260 characters. bruh
    - saulr 11y ago
      Continuing to read the exceptions: > The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
- tobias3 11y ago
  In the Win32 API you can either have * Forward slashes in paths but only 260 characters as max path length * Maximum total path length of 32,767 characters but not forward slashes as path separator Pick your poison.

deleted 11y ago

[deleted]

monochromatic 11y ago

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 11y ago
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 11y ago
  It doesn't help that the various Windows dialogues treat '/' differently. Windows really should have just one file open dialogue, etc.
  - wlesieutre 11y ago
    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.

Animats 11y ago

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

nivla 11y ago
Ya that I too agree with this, pretty much all applications can now deal with \n just fine. Having CR LF (2 Bytes) is not only wasting storage space but also wasting bandwidth when transmitting. While at it, I also wish if Linux distros could get done with case sensitiveness in filenames. Is there any advantage to allowing both Filename.ext and filename.ext? The only time I seen this is when a malware is trying to stay hidden. Also some naming conventions would be nice, when you can have any character including '/' and '.' as a filename, it gets annoying to deal with them in a cli.
- jonathankoren 11y ago
  > Is there any advantage to allowing both Filename.ext and filename.ext? Sorting by ascii order put capitalized files to the top of the list. Exactly where you should look for important stuff like README and Makefile. Case preservation without case sensitivity is just dumb. Why bother, because it's pretty? Also, what's up with spaces in filenames? And furthermore, what are all these kids doing on my lawn?
  - wlesieutre 11y ago
    > Also, what's up with spaces in filenames? What's_up_with_spaces_at_all? Let's_just_join_sentences_with_underscores_for_clarity.
    - cmdrfred 11y ago
      iPreferCamelCase
      - 5ilv3r 11y ago
        kebab-case-is-better

_kst_ 11y ago

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 11y ago
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 11y ago
  Either your system font is weird, or you're dyslectic. Seriously.
  - sp332 11y ago
    *dyslexic
sixothree 11y ago
Akthough this does work dir "c:/*.txt" /w/o/s/p
epsylon 11y ago
Not really a problem since a path never starts with a / in a Windows environment.
- jjnoakes 11y ago
  If one used / as a path separator, then yes, a path could indeed start with / and be confused with options.
JdeBP 11y ago
A simpler example is cd\windows I explicitly and deliberately differed from this when I wrote a command interpreter. * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/cmd/guide/differences.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

skrebbel 11y ago

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 11y ago
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 11y ago
  Probably no source other than: there are 1B+ Windows users (like me) vs. maybe 100M Mac users + a few million Unix-y users.
  - jdietrich 11y ago

jonathankoren 11y ago

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 11y ago

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

hug 11y ago
PS C:\> cd ~/.. PS C:\Users> cd / PS C:\> cd //localhost/c$ PS Microsoft.PowerShell.Core\FileSystem::\\localhost\c$>
rcarmo 11y ago
That is how things work on a Mac.

jasonjei 11y ago

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.

iokanuon 11y ago
Just set up a few symlinks ln -s /mnt/c/Users /home ln -s '/mnt/c/Program Files' /opt ...
wolfgke 11y ago
> 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 Windows does internally - even in a network-transparent way: https://en.wikipedia.org/w/index.php?title=Path_(computing)&oldid=703365694#Uniform_Naming_Convention https://en.wikipedia.org/w/index.php?title=Path_(computing)&...
Arnavion 11y ago
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.
daurnimator 11y ago
> Windows a first-class POSIX development setup. http://midipix.org/ http://midipix.org/ Coming soon :)

skywhopper 11y ago

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.

glandium 11y ago

The best part of using backslashes in paths is that for character encoding historical reasons, backslashes are printed as ¥ in Japan. C:¥Windows¥System32.

TazeTSchnitzel 11y ago

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 11y ago
A more detailed representation of this topic: http://www.howtogeek.com/181774/why-windows-uses-backslashes-and-everything-else-uses-forward-slashes/ http://www.howtogeek.com/181774/why-windows-uses-backslashes... 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=680322555 https://en.wikipedia.org/w/index.php?title=Files-11&oldid=68...)
- zippergz 11y ago
  I used VMS for a while (I never became a power user), and it always felt really weird to me. But I'm not sure if it actually IS weird, or if it just seemed that way because I was already so familiar with Unix. On the one hand, directory separation characters are kind of arbitrary. But my brain insists that "/" is more natural than . (or ":" on MacOS).
  - bbatha 11y ago
    Well VMS also had this nonsense for fully qualified paths, NODE"accountname password"::device:[directory.subdirectory]filename.type;ver everything except filename.type is optional based on the users current DEFAULT (pwd in unix parlance). And required extensions and used the "." separator making it overloaded and confusing to read at a glance. Edit: forgot a few parts of the qualified path.

gozur88 11y ago

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 11y ago
That was intentional to force programs to work with spaces and "special" characters.
- gozur88 11y ago
  If so, that's pretty short-sighted. It's almost impossible to type them out.
- tdeck 11y ago
  Do you have a source for this? It sounds interesting, but also like an urban legend.
- Stratoscope 11y ago
  Naw, it was just to give users "friendlier" directory names like "Program Files" and "Documents and Settings".

dandare 11y ago

Why is backslash called BACK slash when it actually points forward? http://ux.stackexchange.com/questions/92390/why-is-backslash-called-back-slash-when-it-actually-points-forward http://ux.stackexchange.com/questions/92390/why-is-backslash...