Use forward slashes by default in Windows

[chriskuech]

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.

[iSazonov]

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.

[KirkMunro]

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

@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.

@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.

[RokeJulianLockhart]

I agree wholeheartedly. Unless interacting with low-level APIs, I rarely have use for the reverse solidus.

[chriskuech]

@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.

@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.

[vexx32]

@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.

[iSazonov]

Join-Path has AdditionalChildPath which accept string array.

[KirkMunro]

@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.

[mklement0]

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 @Jaykul suggested a looong time ago - see #2993

[lzybkr]

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.

[mklement0]

@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).

[vexx32]

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

[lzybkr]

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.

[KirkMunro]

@iSazonov: This isn't really answered, and should be reopened to allow the ongoing discussion to continue working this out. The OP hasn't even had a chance to respond to questions asked back to him.

[chriskuech]

I think I addressed all the questions to me, but let me know if I didn't. I too am not sure why this issue is closed. It wasn't meant as a discussion thread, rather a feature request.

The root issue at hand:

• Should a cross-platform tool have non-cross-platform behavior by default?
• If so, should there be a way to globally run PowerShell in a "cross-platform" mode?

I think forcing devs to manually normalize strings with cmdlets is a definite wrong move. I don't see any scenarios where using / by default would cause issues on Windows because PowerShell, as previously mentioned, is very good about handling both kinds of slashes. Unless anyone can provide compelling situations where this would cause error, why not just use / by default? Perhaps this issue needs to move to an RFC.

As more people migrate to the cloud, more and more people develop PowerShell code on Windows and run it on Linux. There will certainly be a point in the future (if not already passed) where the number of users preferring true cross-platform behavior exceeds any who feel strongly about keeping \ on Windows.

[iSazonov]

@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.

[aaronfranke]

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

[iSazonov]

Please re-consider your reaction.

@iSazonov , I think @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.

[iSazonov]

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!

[mklement0]

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 @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).

[yecril71pl]

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.

The word slash is US-acceptable, reservations of our British friends notwithstanding, however, it does not mean we should pick it. There are other possibilities which are preferable for other reasons.

[RokeJulianLockhart]

@yecril71pl, I am English, but contradictorily have never witnessed slash refer to urination, nor would anybody that I have ever met understand if I were to utilize it to refer to that. The term is probably colloquially utilized solely within certain few localities. I consequently doubt that it is actually problematic for many people.

To demonstrate that that this anecdote is not mere assumption, I have lived within many large and populous counties – Western Sussex, Norfolk, and Oxfordshire. I knew not of its usage within those regions.

[doctordns]

My personal view is that we should avoid using names that might have inappropriate meanings in major markets. We do not have to deliberately choose names that might be sub-optimal in other cultures.

[yecril71pl]

To demonstrate that that this anecdote is not mere assumption, I have lived within many large and populous counties – Western Sussex, Norfolk, and Oxfordshire. I knew not of its usage within those regions.

Out of curiosity, which county says I knew not? 🤔

[rkeithhill]

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

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

[RokeJulianLockhart]

Although funny, maybe worth marking this as off-topic. Definitely did make me chuckle, though.

[ArielMAJ]

There was too much for me to read here. Was this forgotten or is it being worked on? 😢

This is a problem I'm also running into, in my situation it's when using WSL with PowerShell. e.g.: I want to use valgrind (wsl make ./mycode.c, wsl valgrind ./mycompiledcode), but if i autocomplete it will automatically add a ".\" at the beginning and my command won't work. So I need to fully type names or keep going back and forth correcting the slashes.

It would be amazing if there was an easy way to change the default slash direction on autocomplete or something like that.

[yecril71pl]

AIUI, discussions are for ideas that are not being worked on. Also, you might find the WSL shell more convenient to use for this purpose.

[realInt2k]

hey, I found a temporary solution.

So I frequently have to use the bash command to run *.sh files from my mates, I don't want to switch to wsl, or git-bash. So I did this in \Documents\PowerShell\Microsoft.PowerShell_profile.ps1:

function bash {
  param (
    [string]$dir
  )
  $pattern='\\'
  $string=$dir -replace $pattern, '/'
  & 'C:\Program Files\Git\bin\bash.exe' $string
}

now this command works:
@Dungd ➜ D:\ bash .\docs\nodeApps\useeffect\echo.sh

[mpawelski]

yep, this is the most annoying part: having PS autocomplete \ and having to go back and change it to \. It's not only when working with WSL, sometimes I also find that there are some native CLI apps that also accept only "./", even though they work in Windows.

Some time ago I remember PS team was focused on improving "shell experience", this is one of the area that should be improved.
It's sad to see that something so important to people (basing on the number of feedback in this discussion) has not been taken seriously for almost 4 years now.

[rkitover]

I suggest we follow up on the completion aspect of this in the PSReadLine repo, which is here:

https://github.com/PowerShell/PSReadLine
.

[3N4N]

There was an old feature request already. It didn't come to anything. See my comment for details.

In short, this needs to be implemented in PowerShell engine, not just in a module.

[alanlivio]

Yes, @3N4N I created the request but was not considering it. Did y,ou find a alternative solution?

[alanlivio]

I created this issue in powershell project about this.

[aaronfranke]

I ran into a situation a few weeks ago where I was calling into Bash through PowerShell, but PowerShell automatically replaced / with \, and the \ were treated as escape characters so the path it tried to access was missing slashes. This is unacceptable, it's painful to keep trying to work around the \ problem, I need to be able to set PowerShell to use /.

It's fine if this option doesn't work with every program in every situation. We don't have to make it the default. I just need it to work on my machine without me having to resort to painful workarounds.

[yecril23pl]

The character / is an option separator, meaning the command COPY/B refers to the command COPY, not to the command B.

[aaronfranke]

@yecril23pl / can also be used for directories. This has worked ever since MS-DOS introduced directories.

It is irrelevant that COPY/B works, we do not have to break that for autocomplete to use /. Windows, DOS, CMD, and PowerShell all already support / as a path separator, this issue is just about giving the choice.

[yecril23pl]

If you have a script COPY\B.BAT, you cannot say COPY/B to run it. I am sorry, your assessment is simply wrong 😞

[aaronfranke]

@yecril23pl That is irrelevant, because I can write C:/Users/whatever to refer to a path just fine.

This issue is not about changing the behavior of COPY/B. This is about changing autocomplete to use /, including stopping PowerShell from auto-replacing / with \.

[yecril23pl]

It means that absolute paths are supported, relative paths are not.