Repository navigation
Enable backslash as alternative path delimiter #570
Description
Windows PowerShell allows both \ and / be path delimiters.
Consider
# Full PS on Windows
PS C:\> 'foo' > bar
PS C:\> cat ./bar
foo
PS C:\> cat .\bar
foo
Versus
# Linux version
PSL /Users/vors/dev/PowerShell-Linux> 'foo' > bar
PSL /Users/vors/dev/PowerShell-Linux> cat ./bar
foo
PSL /Users/vors/dev/PowerShell-Linux> cat .\bar
cat : Cannot find path '/Users/vors/dev/PowerShell-Linux/.\bar' because it does not exist.
It's a problem for porting: there are scripts that could run as-is, but don't because of the wrong path delimiters.
On the other hand, on Linux you can create a folder foo\bar, so adding \ as alternative path separator would make this corner case harder.
This problem can be solved with additional escaping
cd foo`\bar
Sidenote: 'Set-Location' (cd) currently fails for it, but Get-ChildItem (ls) works
PSL /Users/vors/dev/PowerShell-Linux> ls ./foo\bar/
Directory: /Users/vors/dev/PowerShell-Linux/foo\bar
Mode LastWriteTime Length Name
---- ------------- ------ ----
------ 2/20/16 9:38 PM 6 1
PSL /Users/vors/dev/PowerShell-Linux> cd ./foo\bar/
cd : An object at the specified path /Users/vors/dev/PowerShell-Linux/foo\bar does not exist.
Activity
andyleejordan commentedon Feb 21, 2016
I'll note that the original developer and PM both preferred not supporting backslash, for various reasons that I can dig up if you wish.
However, I support mapping backslash to slash and using PowerShell's escape character, backtick, to escape a backslash that is needed in an actual path name. But there is a LOT of code that deals with this, all of which would need to be fixed, and would likely better be a task for the PowerShell teams once we're on a unified code base.
palladia commentedon Feb 21, 2016
Linux allows backslash as a valid character in file and directory names. Allowing it to be a directory separator would make things complicated. But interestingly, .NET supports both: altDirectorySeparatorChar
Even on Windows, the mixing of forward and backward slashes isn't as perfect as it could be. We've had to modify many scripts and use Join-Path instead of hard-coded slashes.
zach-folwick commentedon Feb 22, 2016
sergei (@vors) "foo\bar" is a valid filename in *nix. It's also used for directories with spaces; e.g., "Program Files (x86)" would be "Program\ Files\ (x86)".
vors commentedon Feb 22, 2016
Zach Folwick (@zach-folwick) yes, I proposed tick for escaping them in names. For spaces escaping in PS somebody could use quotes around the name, instead of
\on every space.andyleejordan commentedon Mar 1, 2016
From James Truher (@JamesWTruher)
for example this should probably work:
. $HOME/.powershell\profile.ps1
new-item $HOME/.powershell\foo
creates a file ".powershell\foo" in the HOME directory rather than a file "foo" in the $HOME/.powershell directory (additionally, it seems I can't remove this file from within powershell)
As "" is a valid filesystem character, it may be that those paths need to be escaped in some way, but we need to do something - our current users use "" or "/" indiscriminately
andyleejordan commentedon Mar 1, 2016
I am all for reversing the previous decision to make PowerShell on Linux not slash agnostic. Can we do this John W. Fawcett (@FawcettJohnW), Paul Allen (@paulcallen)?
andyleejordan commentedon Mar 1, 2016
AFAICT we would need to add support for
\ escaping the backslash, but once we had that, we could then just interpret unescaped backslashes asDirectorySeparatorChar`.FawcettJohnW commentedon Mar 1, 2016
If I understand the proposal correctly, we would, for Linux, change all \ to /, unless it's escaped. If the user wants xxx\yyy, they can do xxx'\yyy and move forward. Is that correct? If so, it is consistent with other shells and I'm fine with it.
JamesWTruher commentedon Mar 1, 2016
I think we normalize to "/", but allow "". If a user wants a file with a "" in it, they escape it with `\
j
FawcettJohnW commentedon Mar 1, 2016
Yep, sounds good to me.
John
andyleejordan commentedon Mar 1, 2016
Great, this is a go. Editing title and labels.
[-]Should backslash be the alternative path delimiter?[/-][+]Enable backslash as alternative path delimiter[/+]7 remaining items
andyleejordan commentedon May 19, 2016
James Truher (@JamesWTruher) sergei (@vors) I think we can at least start with reverting the changes that were made to get us here in the first place, and then work from there to ensure backslashes as valid characters are fully supported via escaping. I'm probably more familiar with the original changes than anyone else, shall I take this on?
joeyaiello commentedon May 19, 2016
Let me ask a more general question: can we track/tag all the changes that need to be made in some way so that if we receive strong user feedback to reverse the decision, we easily can?
andyleejordan commentedon May 19, 2016
Well, yes. They'll be in Git.