search

microsoft / Windows-Dev-Performance

A repo for developers on Windows to file issues that impede their productivity, efficiency, and efficacy
MIT License
434 stars 20 forks source link

Consider making / directory separator for file paths the default for consistency against other operating systems #82

Closed xPaw closed 3 years ago

xPaw commented 3 years ago

Environment

Item Value
OS, Version / Build 10.0.19042.0 (any applies)

Description

Historically, Windows is odd one out by using \ over / for dir separators. For developers this is especially annoying.

Windows 10 understands / everywhere as far as I am aware.

With Microsoft pushing for developer ecosystem on Windows, I think this might a good idea to revist these artifacts of history and perhaps update the defaults, or at least provide some kind of option for developers to set.

https://twitter.com/thexpaw/status/1361263999468384257

Steps to reproduce

  1. Open a terminal, paths will be using \ for directory separators.

Expected behavior

  1. Terminal and other software should use / for directory separators.

Actual behavior

sylveon commented 3 years ago

There are many programs which still treat \ as "the only" path separator on Windows, despite this not being true for a while (I've recently had to fix a library for that myself: https://github.com/gabime/spdlog/pull/1787).

Such a change (making APIs return paths with forward slashes instead of backslashes) will have significant backwards compatibility consequences.

justanotheranonymoususer commented 3 years ago

Such a change (making APIs return paths with forward slashes instead of backslashes) will have significant backwards compatibility consequences.

It can be opt-in with a manifest declaration, just like it was done with UTF-8.

bitcrazed commented 3 years ago

Polite ask: Please file separate issues for separate problems/suggestions.

Closing this issue as won't fix because:

  1. Preventing the use of \ as a path separator would break hundreds of millions of scripts, apps, and tools, cause many businesses and potentially several countries to collapse. This is not an exaggeration - many of the systems that support modern businesses and economies rely on decades-old scripts, apps, and tools that contain/generate paths separated by \ and will fail and crash if they could not.

  2. There isn't some magical function in Windows that parses/emits CRLF as a line ending - this behavior is hard-coded into hundreds of millions of apps, tools, scripts, etc. many of which will break if CRLF is replaced with LF, again, likely crashing millions of systems, businesses, and even several nations.

    As an aside, CRLF is actually something Microsoft got right. CR moves the cursor all the way to the left, LR moves the cursor down one line. Abbreviating CRLF to LF is a lossy *NIXism.

👉 Note: Rather than preventing the use of \ as a path separator, Windows now also supports / as a path separator in many places, including File Explorer, and PowerShell.

xPaw commented 3 years ago

Please file separate issues for separate problems/suggestions.

I did split the issue out.

Preventing the use of \ as a path separator

The suggestion is not to prevent it, but change the default which is used to display paths, like in the terminal: xPaw in C:\Users. or when pressing tab to auto complete paths.

justanotheranonymoususer commented 3 years ago

Your arguments don't hold water IMO, Rich. Similar things have done before without breaking compatibility. Those things can be opt-in and co-exist while being in a deprecation phase. But I think the real reason it won't happen is because it's work, which costs time and money, for an annoying inconsistence that people just learned to live with.

sylveon commented 3 years ago

The suggestion is not to prevent it, but change the default which is used to display paths, like in the terminal: xPaw in C:\Users. or when pressing tab to auto complete paths.

Opening an issue specifically for that (support forward / in auto-completion and path display for CMD/PowerShell) would hold much more ground than a blanket "make / the separator" issue.

xPaw commented 3 years ago

Opening an issue specifically for that (support forward / in auto-completion and path display for CMD/PowerShell) would hold much more ground than a blanket "make / the separator" issue.

But that doesn't really get us anywhere in terms of the whole Windows ecosystem. I didn't expect this issue to gain any traction, I just threw it out there.

sylveon commented 3 years ago

Doubt the whole Windows ecosystem will ever completely move away from the 30+ years legacy of \

bitcrazed commented 3 years ago

@justanotheranonymoususer You have opt-in today - you can choose to use the / path separator in your PowerShell scripts if you wish.

This isn't about it causing us (Microsoft) work - it's about not breaking existing apps, tools, customers, businesses, etc.

And while this may be an annoyance for *NIX users, The \ path separator is the norm for Windows users who are the majority of users on Windows.

justanotheranonymoususer commented 3 years ago

you can choose to use the / path separator in your PowerShell scripts

Yes, but you can't make powershell display or auto-complete /, right? Or, for example, type C:/ in the Run dialog or in file explorer. No auto-complete, unlike C:\. Basically, it's not a first class citizen.

The \ path separator is the norm for Windows users who are the majority of users on Windows.

That I agree with.

I don't have strong feelings about it, and I hardly see it happen, I just thought that your arguments weren't convincing enough.

bitcrazed commented 3 years ago

No - the formal path separator is the backslash \. The forward slash / is an accommodation and cannot be used everywhere as it will sometimes be interpreted as a switch separator.

If you'd like to petition the PowerShell team to provide a config setting controlling which path separator char to display in file paths etc., then please do so: http://github.com/powershell/powershell. However, note that this won't change the way paths are displayed in Cmd, nor Explorer, etc.

FWIW, The decision for which chars were used for switches and path-separators date all the way back to ~1982 when the switch char (/) and path separator char () were declared in the source code of MS-DOS 2.0 which added hierarchical directories/folders. https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/COMMAND.ASM#L518-L521

justanotheranonymoususer commented 3 years ago

I'm not here to achieve that. I just provide my opinion on @xPaw's issue which I think is worth a discussion, as unreal as it might be short term.

Actually, I'm here (in this repo) because of this issue. Something is really wrong there in the help catalog, and I'm upset because I rely on it for some task. @bitcrazed, using a chance of talking with a Microsoft guy, can you help me find the contact for that? I tried everything I found - the forums, the feedback hub, the feedback at the lower part of the website, this repo. What else can I do apart from screaming about it in the forests?