Hacker News Reader

Comment by gdulli | Hacker News Reader

Are there contexts where the backslash is still required? I've been using the forward slash in Windows for years. It works from Python, it works from the command prompt, it works in Explorer. But I don't know if that means it's completely redundant or if some places still require it.

View on HN

Because the forward slash is used for command line flags, there can be ambiguity when using forward slashes in paths that does not exist if using backslashes. Consider a directory on your root C: drive called "D". In a command prompt:

cd \D <-- This takes you to the C:\D\ directory.

cd /D <-- This is an error because /D is a flag.

True, but quoting the path will work: cd "/D"

How? Wouldn't the program's argv see the same string with and without quotes? Or is that just a *nix thing?

cd is a built-in of the shell / cmd, not an application, it does not use argv, AFAIK.

It should, as you said, not work for normal applications

nope. I read an article about this when i accidentally broke the arg parsing for wildcards. worked fine in linux, but not on windows :(

In Win32, argv is not part of the OS process API. The processes get the entire command line as a string, and have to parse it themselves - or, more commonly, leave it up to the C runtime.

But in this case, I don't think it matters.

This is interesting regarding args. https://nullprogram.com/blog/2022/02/18/

No, it doesn't. Try it and see for yourself. Make sure you're using Command Prompt and not PowerShell.

I made a typo while checking this, and amusingly while neither cd /D nor cd "/D" work, cd "/D? does.

At the API level, both '/' and '\' have been accepted since sub-directories were added to DOS.

It was only ever at the UI (command prompt), and in how some programs converted inputs and outputs where '\' was necessary, as the knowledge about '/' being usable wasn't all that widespread.

What used to peeve me was C source on DOS development environments with lines like:

  #include "path\\to\\file.h"

When the following always seemed to work (with the compilers I used):

  #include "path/to/file.h"

Or at least it did with Borland compilers.

This post isn’t about file paths but command line arguments

I think \\?\ paths require backslashes.

It doesn't tab complete the path if you use forward slash in windows batch. I think forward slash works right in PowerShell, but I might be mistaken.

it works just fine in PowerShell and the new Windows Terminal but yeah, I doubt CMD will do auto-complete for you w/ forward slash

It will not. It completes out of the current directory when trying to TAB-complete following a slash.

Powershell will autocomplete forward-slash paths and convert them to back slashes.

It's required when passing a path as argument to Explorer. That is, when you type "explorer C:/" in the Run box or on the command line, Explorer opens in the default folder instead of in C:\. That's probably because Explorer also accepts URLs, so "explorer file://C:/" does work. For some reason, the Explorer address bar behaves differently.

Any / that occurs in an unquoted command line argument is going to be treated as a separator, so you've effectively invoked "explorer C: /".

That depends on the application’s argument parser.

That's the de facto standard for command line apps that ship with Windows itself.

Also, the Registry.

And BTW .reg files need to double the backslash because it is parsed as an escape character.

They are still needed in UNC paths like \\server\...\.

UNC paths like //server/share/ are perfectly fine.

I tried it in Windows Explorer on Windows 10, and it just launches the browser for me instead of opening the folder.

CMD and Windows Explorer don't like that. Powershell handles it fine.

Reply on news.ycombinator.com