Use forward slashes by default in Windows

Summary of the new feature/enhancement

PowerShell aims to be cross-platform, but I have been having many issues operating on paths across both Windows and Linux. I understand the need to support \ in Windows for the foreseeable future, but I would at least like the default path character to be the same on both Windows and *nix, presumably by setting the default path delimiter to /. The current alternative is forcing users to normalize paths themselves with -replace "\\", "/" in their paths.

The current alternative is forcing users to normalize paths

PowerShell already does the work for you and you have no need to normalize paths.
PowerShell is very user-friendly here - users can use slashes which they are comfortable regardless of platform.
Best practice is to avoid using literal paths and use path cmdlets.

Ilya (@iSazonov)

Best practice is to avoid using literal paths and use path cmdlets.

Ilya (@iSazonov) Yes and no.

Sure, if you are combining path segments, you can use path cmdlets. But if you are writing a script that references a relative path with multiple segments, and if you intend for your script to work cross platform, you're not going to do that.

In PowerShell 7 preview 3 on Windows, tab completion completes paths using a backslash. That is the one place where I think we're doing it wrong now that PowerShell is cross platform. There should at least be an option to select the directory separator character you want used on Windows as part of tab completion: either [System.IO.Path]::DirectorySeparatorChar or [System.IO.Path]::AltDirectorySeparatorChar. Given where we are today, I suspect most folks who do any cross platform work would want tab completion of paths to use AltDirectorySeparatorChar on Windows by default, but as far as I know there is no way to make it do that.

Chris Kuech (@chriskuech): Aside from tab completion of paths, are there other places where you feel AltDirectorySeparatorChar isn't being used where you would like to have an option for it to be used instead of DirectorySeparatorChar? I can't think of any.

Kirk Munro (@KirkMunro)

Kirk Munro (@KirkMunro) , are you saying that there is an (at least partially implemented) way to normalize paths in PowerShell today? If so, will it work on latest 6.x? The use cases I was having an issue with were automatic variables and *-Path commands.

Ilya (@iSazonov), the proposed solution would not have worked for my scenario because I generated a list of paths on Windows, generated a list of paths on Linux, then attempted to compare them, which failed due to the separators.

The automatic variables consistently lack a trailing directory separator, so PowerShell beautifully allows creating paths with literals. Ex:

$RepoRoot = "$PSScriptRoot/../.."
$SourceRoot = "$RepoRoot/src"
$BuildRoot = "$RepoRoot/.build"

I think this is much more clear than

$RepoRoot = Join-Path $PSScriptRoot "../.."
$SourceRoot = Join-Path $RepoRoot "src"
$BuildRoot = Join-Path $RepoRoot ".build"

so I hope it can work in the future, even if not by default.

Chris Kuech (@chriskuech)

Chris Kuech (@chriskuech) my personal habit has become something like:

$SourceRoot = $RepoRoot | Join-Path -ChildPath 'src'

It's a little clearer but yeah it's not perfect.

Join-Path has AdditionalChildPath which accept string array.

Chris Kuech (@chriskuech)

Chris Kuech (@chriskuech) Thanks for the additional information.

I wasn't suggesting that PowerShell partially supports normalization of paths. I was simply calling out that I personally dislike that tab completion uses a backward slash by default on Windows, and a forward slash by default on Linux or macOS.

If I could tweak some setting to change that so that forward slash is used even on Windows paths by default, I would make that change, and this is one place where I think there may be an opportunity to make cross platform PowerShell work easier. Join-Path uses [System.IO.Path]::DirectorySeparatorChar as the path separator as well. Ideally if there were a setting to set the desired path separator when writing scripts (because we should be able to easily write scripts the way we want regardless of the platform we choose to write them on), it would be reflected in both tab completion of paths and Join-Path as well.

Those personal needs aside, I wonder if a Compare-Path cmdlet would be useful. It could normalize the path separators, and even compare absolute paths with relative paths by resolving relative paths before the comparison is made if one of the paths is absolute.

Joel Bennett (@Jaykul)

Well, we do get platform-specific normalization in Convert-Path and Resolve-Path:

PS> Convert-Path C:/Windows
C:\Windows # normalized to Windows-native "\"

So, perhaps as an alternative to introducing a Compare-Path cmdlet, Convert-Path and Resolve-Path could be extended to support a -UseSlash switch (name negotiable).

Separately and complementarily, the opt-in preference mechanism for using / on Windows that Kirk suggests could then also apply to Convert-Path and Resolve-Path (in addition to tab completion and Join-Path).

The catch at the moment is that Convert-Path and Resolve-Path only work with existing paths, but that is something well worth changing in its own right, as Joel Bennett (@Jaykul) suggested a looong time ago - see #2993

I think it would be nice if path completion used the path separator that appears explicitly in the completion text, and if there is none, then default to the platform native separator.

So on Windows, c:\w completes to c:\Windows\ and c:/w completes to 'c:/Windows/'.

I think this would cover a majority of the annoyances without requiring a configuration option, and is actually preferable because you occasionally might need the other form for whatever reason.

Jason Shirk (@lzybkr)

Jason Shirk (@lzybkr), I like the idea, also in light of a concern regarding a configuration- / preference-variable-based solution that I neglected to mention: the scoping issue; with the usual dynamic scoping, code that makes fixed assumptions about path separators may break (which has echoes of PowerShell/PowerShell-RFC#7).

Jason Shirk (@lzybkr)

Jason Shirk (@lzybkr) and when both slashes are used? C:\Program Files/A -> ?

So many options - random, alternate each one, always forward slash b/c it's the one true path separator, etc.

More seriously, maybe just pick the last one used, that is probably typed by the user whereas others might not be.

Thomas Lee (@doctordns)

Thomas Lee (@doctordns) Don't use street and prison jargon in this respected community
https://github.com/PowerShell/PowerShell/blob/master/CODE_OF_CONDUCT.md

GitHub
PowerShell/CODE_OF_CONDUCT.md at master · PowerShell/PowerShell
PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

Yes, there's no need to have "Slash" in the name. PSPathSeparatorChar or similar makes sense to me.

Ilya (@iSazonov)

Please re-consider your reaction.

Ilya (@iSazonov) , I think Thomas Lee (@doctordns)' point was that a name being considered in this discussion for an official preference variable might be offensive to some, and he explained why.

Such discussions are not acceptable here.
Official linguistic sources do not consider the term offensive. You can find thousands of uses of the term in GitHub repositories and directly in the code.
The correct procedure is described in the CoC. If anyone has a different opinion, follow the CoC. https://github.com/PowerShell/PowerShell/blob/master/CODE_OF_CONDUCT.md

GitHub
PowerShell/CODE_OF_CONDUCT.md at master · PowerShell/PowerShell
PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

To be clear, my objection was not to the warning, but to the sordid details.
This is categorically unacceptable in the repository.
A gentle warning is enough for PowerShell Committee to take it into account in case they discuss the issue. (For the record, Microsoft already has a list of forbidden terms.)

Once again, please stop discussing in this direction and switch to constructive suggestions.
If someone wants to clean up all of GitHub from millions of uses of the term, they can find the contacts of Microsoft responsible group at CoC.
Please read FAQ there to understand the resolution process. Notice, the process is private - maybe it will give you an understanding of why you shouldn't discuss it publicly here.
If you still prefer otherwise, please use other forums. Here focus on PowerShell development.
Thanks for understanding!

Aaron Franke (@aaronfranke)

To be clear, my objection was not to the warning, but to the sordid details.

There were no sordid details - unless you consider a clinical term for a bodily function "sordid".

And it should be self-evident that some description of the potentially offensive meaning of the term in question is necessary.

To also be clear: I have no stake in this discussion (to me the term isn't offensive), but I find this baffling overreaction to a concern voiced by a user in good faith disconcerting.

As for the actual discussion at hand:

FWIW, the current references in the help topics don't use the term in isolation (and I'm not aware of code elements using it at all) - they use backslash and forward slash (again, not a personal concern of mine).

As for constructive suggestions: the discussion already encompasses that too - see Aaron Franke (@aaronfranke)'s comment.

I understand your argument that the word is commonly used and should therefore be regarded as acceptable, and perhaps that is ultimately the proper resolution to this discussion.

But there should be always be room for such a discussion (as long as the language used in the discussion doesn't violate the CoC, which I think was definitely not the case here).

Or we could just skip using that "word" altogether Prince style, and use images instead: 🤣

OK, had my fun, backing away from the keyboard.

Navigation Menu

Repository navigation

Use forward slashes by default in Windows #10509

Summary of the new feature/enhancement

79 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Use forward slashes by default in Windows #10509

Description

Summary of the new feature/enhancement

Activity

iSazonov commented on Sep 11, 2019

KirkMunro commented on Sep 11, 2019

chriskuech commented on Sep 11, 2019

vexx32 commented on Sep 11, 2019

iSazonov commented on Sep 12, 2019

KirkMunro commented on Sep 12, 2019

mklement0 commented on Sep 12, 2019

lzybkr commented on Sep 12, 2019

mklement0 commented on Sep 12, 2019

vexx32 commented on Sep 12, 2019

lzybkr commented on Sep 12, 2019

mklement0 commented on Sep 13, 2019

79 remaining items

doctordns commented on Dec 23, 2021

iSazonov commented on Dec 23, 2021

mklement0 commented on Dec 23, 2021

doctordns commented on Dec 23, 2021

yecril71pl commented on Dec 23, 2021

aaronfranke commented on Dec 23, 2021

iSazonov commented on Dec 24, 2021

yecril71pl commented on Dec 24, 2021

doctordns commented on Dec 24, 2021

mklement0 commented on Dec 24, 2021

iSazonov commented on Dec 24, 2021

mklement0 commented on Dec 24, 2021

rkeithhill commented on Dec 24, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions