6 ms·

It should be noted that Windows can use either forward or backward slashes nowadays. In fact, even File Explorer allows you to use an unholy mix of the two.

Doubl 7y ago
Yes I'd noticed this once or twice and momentarily wondered why there wasn't a problem. I hadn't realised it was now officially ok
- Stratoscope 7y ago
  It's useful to distinguish between command line and GUI apps vs. the operating system itself. Forward slashes and backslashes have been supported as path delimiters all the way back to MS-DOS 2.0 when hierarchical directories were first introduced. The DOS and Windows file APIs never cared which you used. It was only command line and GUI apps that (rightly or wrongly) preferred one or the other. The only new thing here is that some of these apps have finally started to recognize either delimiter. That is a tricky thing for a command line app where the wrong slash may be interpreted in a way the user did not mean. For GUI programs there was never a good reason to not accept both, e.g. in a file path field.
dfawcus 7y ago
As I recall, so could / would DOS - at the Int21 syscall level. The SWITCHAR option was present to set a value which COMMAND.COM (and other DOS utils) consulted such that one could make it honour '-' as the flag leader, and then accept '/' at COMMAND.COM (and other DOS utils). Unfortunately not all third party utils honoured that, and so it usually ended up not being worth flipping it in to Unix compatible mode. That said, one could take advantage of the recognition of '/' in programs one wrote, e.g. C code (so avoiding "directory\\file.txt").
- spc476 7y ago
  INT 21h, function 37h could be used to get and set the switch character for MS-DOS, in addition to requiring the use of '/DEV/' for device filenames: * AL=0, return switch character in DL * AL=1, set switch character to character in DL * AL=2, return '/DEV/' setting in DL * AL=3, DL=0 if '/DEV/' required, DL<>0 if not. Okay, why do I remember this stuff? I haven't programmed MS-DOS for over 25 years!
duxup 7y ago
I accidentally typed the a mix once and noticed it when I hit enter. I honestly expected a blue screen... and I probabbly would have accepted that as the proper outcome of crossing the streams. But it worked. I'm still not sure how I feel about it working...
- blattimwind 7y ago
  Now mount your NTFS volume on Linux and create a directory named "foo\bar", then a directory "foo" and a directory "bar" inside "foo".
  - AdamGibbins 7y ago
    What happens?
    - ithkuil 7y ago
      Not sure. I'd expect the "foo\bar" created on that NTFS volume while mounfed from Linux to be effectively unreachable when accessed from windows (at least while the command line?). Or not. Surprise me.
      - ahakki 7y ago
        Works without issue. Just went to the Store, downloaded Ubuntu LTS 18.4 and tried it. Screenshot: https://1drv.ms/u/s!AqSptDJA-vctqs4OGewT6Qa-PWBvbw https://1drv.ms/u/s!AqSptDJA-vctqs4OGewT6Qa-PWBvbw
        Jetroid 7y ago
        I think the intention was that 'foo/bar' and 'foo' would be in the same directory, therefore when typing C:\foo/bar into the file explorer you would have an ambiguous path. Perhaps I misunderstood.
      - Zancarius 7y ago
        You can create file names containing special characters from ntfs-3g that make it nearly impossible to access or remove from within Windows (such as those containing a "?" character). I'm sure there's a way, but neither the command prompt nor Windows Explorer know what to do. Opening such files from a variety of test applications seems to fail as well. According to the ntfs-3g FAQ, this is expected behavior[1] and is a consequence of NTFS' namespace implementation. Allegedly, such files could be removed via a Samba client, but I've never tried. I confess that outside mounting the disk under Linux, I know of no first party solution to remove or rename such files; but, I'm also not especially knowledgeable on Windows internals. [1] https://web.archive.org/web/20090207135653/http://ntfs-3g.org/support.html#posixfilenames2 https://web.archive.org/web/20090207135653/http://ntfs-3g.or...
kazinator 7y ago
Every Microsoft operating system going back to early versions of MS-DOS can use / as the separator. This is not necessarily true of the "user space" of Microsoft systems. Paths are not only traversed by the "kernel", but also manipulated by applications like the Explorer shell, which may or may not like forward slashes.
- ChrisSD 7y ago
  As I recall at least some parts of the WinAPI had trouble if you used long paths (via "\\?\") and forward slash. I don't know if that's still true.
  - kazinator 7y ago
    Indeed. "Windows API" is very broad; it encompasses all sorts of user-space middleware, some of which could very plausibly munge paths in ignorance of forward slashes.
- mortehu 7y ago
  It's partially the opposite. Some system calls only accept backlash, but user space programs and libraries may abstract this. E.g. LoadLibrary, which is similar to execve/dlopen.
dataflow 7y ago
It should also be noted that you should NOT get in the habit of doing this because the command prompt is not really amused by you doing this. (Try running foo/bar.exe.)
- ChrisSD 7y ago
  Try it again with Powershell...
psyklic 7y ago
Interestingly, "unholy mixes" of slashes only always work properly in old Windows paths! I found this out when debugging an open source project where '/file.txt' (hardcoded as a forward slash) was appended to a "\\?\" path. Microsoft introduced "extended paths" to accommodate Unicode and paths longer than 260 characters (i.e. "C:\<256-char string>"). These can be prefixed by "\\?\", which sadly does not support slash mixes. Rust's standard library `canonicalize` function, for example, returns "\\?\" paths! (* EDIT: I originally wrote some historical inaccuracies, see ynik's reply below for the corrections. Thank you ynik!) From the docs: "File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix." - https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation https://docs.microsoft.com/en-us/windows/desktop/FileIO/nami...
- deleted 7y ago
  [deleted]
- ynik 7y ago
  The "\\?\" extended-length paths have existed for a long time; I think since Windows 2000 at least. The Windows kernel and NTFS have always supported paths up to 32k characters; only the Win32 path normalization logic was limited to MAX_PATH. The "\\?\" prefix skips the normalization logic, thus allowing apps to use the full path length. The Windows 10 change in 2016 is something different: if an application opts in (via manifest) AND the LongPathsEnabled registry key is set, long paths will be supported by some (not all) Windows API functions even without the "\\?\" prefix. These new long paths support a mixture of slashes just fine.
  - vbezhenar 7y ago
    This is some incredible level of compatibility. Cudos to MS stance on that subject.
  - Dylan16807 7y ago
    To be extra pedantic, it's 32k code units, so some characters take up two.
b_tterc_p 7y ago
I confess, I use them interchangeably and don’t know which one is “correct”
- other_herbert 7y ago
  Just as long as you don't say backslash when saying a URL... that is one of the things that really brings out the pedant in me...
A2017U1 7y ago
No tab completion in shells for forward slashes though :(
- thatfunkymunki 7y ago
  I think tab completion for forward slashes works in powershell
DonHopkins 7y ago
I accidentally found out something mind blowing about Mac OS/X recently: The Finder apparently lets you use "/" in file names! I expect you won't believe me, so try it. Now look at the file in the shell with "ls". Go figure! Now who's unholy???
- thristian 7y ago
  Classic Mac OS allowed filenames to contain every character except the directory-delimiter, ":". When Mac OS X came around, it included a POSIX API and kernel (so applications expect to be able to use ":" in filenames), but used the same filesystem as Classic Mac OS which didn't allow ":" but did allow the POSIX directory separator "/", which POSIX apps wouldn't try to use in a filename. And so at some layer they were switched around - if you try to create a filename with "/" in the GUI, it's presented as ":" to POSIX; if a POSIX app creates a filename with ":" it shows up as "/" in the GUI.

Doubl 7y ago

Yes I'd noticed this once or twice and momentarily wondered why there wasn't a problem. I hadn't realised it was now officially ok

Stratoscope 7y ago
It's useful to distinguish between command line and GUI apps vs. the operating system itself. Forward slashes and backslashes have been supported as path delimiters all the way back to MS-DOS 2.0 when hierarchical directories were first introduced. The DOS and Windows file APIs never cared which you used. It was only command line and GUI apps that (rightly or wrongly) preferred one or the other. The only new thing here is that some of these apps have finally started to recognize either delimiter. That is a tricky thing for a command line app where the wrong slash may be interpreted in a way the user did not mean. For GUI programs there was never a good reason to not accept both, e.g. in a file path field.

dfawcus 7y ago

As I recall, so could / would DOS - at the Int21 syscall level. The SWITCHAR option was present to set a value which COMMAND.COM (and other DOS utils) consulted such that one could make it honour '-' as the flag leader, and then accept '/' at COMMAND.COM (and other DOS utils). Unfortunately not all third party utils honoured that, and so it usually ended up not being worth flipping it in to Unix compatible mode. That said, one could take advantage of the recognition of '/' in programs one wrote, e.g. C code (so avoiding "directory\\file.txt").

spc476 7y ago
INT 21h, function 37h could be used to get and set the switch character for MS-DOS, in addition to requiring the use of '/DEV/' for device filenames: * AL=0, return switch character in DL * AL=1, set switch character to character in DL * AL=2, return '/DEV/' setting in DL * AL=3, DL=0 if '/DEV/' required, DL<>0 if not. Okay, why do I remember this stuff? I haven't programmed MS-DOS for over 25 years!

duxup 7y ago

I accidentally typed the a mix once and noticed it when I hit enter. I honestly expected a blue screen... and I probabbly would have accepted that as the proper outcome of crossing the streams. But it worked. I'm still not sure how I feel about it working...

blattimwind 7y ago
Now mount your NTFS volume on Linux and create a directory named "foo\bar", then a directory "foo" and a directory "bar" inside "foo".
- AdamGibbins 7y ago
  What happens?
  - ithkuil 7y ago
    Not sure. I'd expect the "foo\bar" created on that NTFS volume while mounfed from Linux to be effectively unreachable when accessed from windows (at least while the command line?). Or not. Surprise me.
    - ahakki 7y ago
      Works without issue. Just went to the Store, downloaded Ubuntu LTS 18.4 and tried it. Screenshot: https://1drv.ms/u/s!AqSptDJA-vctqs4OGewT6Qa-PWBvbw https://1drv.ms/u/s!AqSptDJA-vctqs4OGewT6Qa-PWBvbw
      - Jetroid 7y ago
        I think the intention was that 'foo/bar' and 'foo' would be in the same directory, therefore when typing C:\foo/bar into the file explorer you would have an ambiguous path. Perhaps I misunderstood.
    - Zancarius 7y ago
      You can create file names containing special characters from ntfs-3g that make it nearly impossible to access or remove from within Windows (such as those containing a "?" character). I'm sure there's a way, but neither the command prompt nor Windows Explorer know what to do. Opening such files from a variety of test applications seems to fail as well. According to the ntfs-3g FAQ, this is expected behavior[1] and is a consequence of NTFS' namespace implementation. Allegedly, such files could be removed via a Samba client, but I've never tried. I confess that outside mounting the disk under Linux, I know of no first party solution to remove or rename such files; but, I'm also not especially knowledgeable on Windows internals. [1] https://web.archive.org/web/20090207135653/http://ntfs-3g.org/support.html#posixfilenames2 https://web.archive.org/web/20090207135653/http://ntfs-3g.or...

kazinator 7y ago

Every Microsoft operating system going back to early versions of MS-DOS can use / as the separator. This is not necessarily true of the "user space" of Microsoft systems. Paths are not only traversed by the "kernel", but also manipulated by applications like the Explorer shell, which may or may not like forward slashes.

ChrisSD 7y ago
As I recall at least some parts of the WinAPI had trouble if you used long paths (via "\\?\") and forward slash. I don't know if that's still true.
- kazinator 7y ago
  Indeed. "Windows API" is very broad; it encompasses all sorts of user-space middleware, some of which could very plausibly munge paths in ignorance of forward slashes.
mortehu 7y ago
It's partially the opposite. Some system calls only accept backlash, but user space programs and libraries may abstract this. E.g. LoadLibrary, which is similar to execve/dlopen.

dataflow 7y ago

It should also be noted that you should NOT get in the habit of doing this because the command prompt is not really amused by you doing this. (Try running foo/bar.exe.)

ChrisSD 7y ago
Try it again with Powershell...

psyklic 7y ago

Interestingly, "unholy mixes" of slashes only always work properly in old Windows paths! I found this out when debugging an open source project where '/file.txt' (hardcoded as a forward slash) was appended to a "\\?\" path. Microsoft introduced "extended paths" to accommodate Unicode and paths longer than 260 characters (i.e. "C:\<256-char string>"). These can be prefixed by "\\?\", which sadly does not support slash mixes. Rust's standard library `canonicalize` function, for example, returns "\\?\" paths! (* EDIT: I originally wrote some historical inaccuracies, see ynik's reply below for the corrections. Thank you ynik!) From the docs: "File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix." - https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation https://docs.microsoft.com/en-us/windows/desktop/FileIO/nami...

deleted 7y ago
[deleted]
ynik 7y ago
The "\\?\" extended-length paths have existed for a long time; I think since Windows 2000 at least. The Windows kernel and NTFS have always supported paths up to 32k characters; only the Win32 path normalization logic was limited to MAX_PATH. The "\\?\" prefix skips the normalization logic, thus allowing apps to use the full path length. The Windows 10 change in 2016 is something different: if an application opts in (via manifest) AND the LongPathsEnabled registry key is set, long paths will be supported by some (not all) Windows API functions even without the "\\?\" prefix. These new long paths support a mixture of slashes just fine.
- vbezhenar 7y ago
  This is some incredible level of compatibility. Cudos to MS stance on that subject.
- Dylan16807 7y ago
  To be extra pedantic, it's 32k code units, so some characters take up two.

b_tterc_p 7y ago

I confess, I use them interchangeably and don’t know which one is “correct”

other_herbert 7y ago
Just as long as you don't say backslash when saying a URL... that is one of the things that really brings out the pedant in me...

A2017U1 7y ago

No tab completion in shells for forward slashes though :(

thatfunkymunki 7y ago
I think tab completion for forward slashes works in powershell

DonHopkins 7y ago

I accidentally found out something mind blowing about Mac OS/X recently: The Finder apparently lets you use "/" in file names! I expect you won't believe me, so try it. Now look at the file in the shell with "ls". Go figure! Now who's unholy???

thristian 7y ago
Classic Mac OS allowed filenames to contain every character except the directory-delimiter, ":". When Mac OS X came around, it included a POSIX API and kernel (so applications expect to be able to use ":" in filenames), but used the same filesystem as Classic Mac OS which didn't allow ":" but did allow the POSIX directory separator "/", which POSIX apps wouldn't try to use in a filename. And so at some layer they were switched around - if you try to create a filename with "/" in the GUI, it's presented as ":" to POSIX; if a POSIX app creates a filename with ":" it shows up as "/" in the GUI.