Is there a way to make Powershell use forward slashes instead of backslashes for path autocompletion?

Question

Lately I have been using the wsl command to run Linux (Ubuntu) binaries and commands within powershell.

For instance:

ls | wsl grep 'log'

I was trying to use vim to open a file named .htaccess but I didn't want to type the full name of the file. So instead I just typed wsl vim .ht and pressed tab to have powershell autocomplete the path. This autocompleted to wsl vim .\.htaccess which seemed fine but when I pressed enter, vim opened a new file named ..htaccess (notice the additional period). That's when I realized that it was using the Windows' directory separator of backslash instead of forward slash. Presumably the backslash just escaped the period which is why in vim it was trying to create a new file named ..htaccess.

I was wondering if there is any way to tweak powershell so that it uses forward slashes for path autocompletion instead of backslash. I know that lately Windows understands and translates forward slashes.

For example, this command works in powershell:

cd C:/Windows

Even though Windows uses backslash, this command worked and brought me to C:\Windows. So is there a way to make autocompletion use forward slash?

Answer 1

I try to avoid "negative answers", but sometimes there's not much of a choice. At present, I can't think of any good way to do this. There was a Github issue/feature request for this earlier this year, and the PowerShell PSReadLine team replied with it being "As designed".

Just in case, though, I looked through the Get-PSReadLineOption options that are available, but there's no option for the path separator in there.

There's [IO.Path]::DirectorySeparatorChar, but as a comment on this answer points out, it's read-only.

In considering possible alternatives, I couldn't come up with much:

• There might be a way to wrap a PowerShell function around your wsl call in a generic enough way that it could handle different commands. The function would need to parse out the arguments and run a wslpath command around any paths.

  The wslpath command is installed by default in some WSL distributions (Ubuntu, at least) and can be installed on others via the wslu package.

  E.g. wslpath "C:\\" returns /mnt/c

  But then we also get into double-backslash quoting issues, etc. Ultimately, I dismissed this as too hacky and likely to be very "fragile".

• I believe you could handle this in a .NET ArgumentCompleter for the wsl command. I've written one that handles the various flags for the WSL command that you are welcome to use as a base.

  I'm just not sure how difficult it would be to re-write the completer for files/directories, but I have a feeling it's not worth the effort.