Repository navigation
Some cmdlets don't respect -LiteralPath when it comes to backslashes #8158
Description
Path normalization (fixing of slashes) is happening regardless of whether -literalpath is used. Seen in Set-Content, Get-Content, Out-File (maybe others, search for NormalizePath()
Steps to reproduce
# on Unix based system
Set-Content -LiteralPath "\foo.txt" -Value "bar"Expected behavior
A file called "\foo.txt" is created with content "bar"
Actual behavior
Path normalization (fixing slashes) doesn't take into account that this is a literal path.
Set-Content : Access to the path '/foo.txt' is denied.
At line:1 char:1
+ Set-Content -LiteralPath "\foo.txt" -Value "bar"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (/foo.txt:String) [Set-Content], UnauthorizedAccessException
+ FullyQualifiedErrorId : GetContentWriterUnauthorizedAccessError,Microsoft.PowerShell.Commands.SetContentCommand
Environment data
Name Value
---- -----
PSVersion 6.2.0-preview.1
PSEdition Core
GitCommitId 6.2.0-preview.1
OS Darwin 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Activity
mklement0 commentedon Oct 31, 2018
Given that
\is not a wildcard-expression metacharacter, I would expect it to be treated as a literal in-Patharguments too.In #6833 (comment) you've talked about the need to support escaping
\in paths, without being specific about-Pathvs.-LiteralPath:To me it makes sense to treat the
\issue separately from the-Path/-LiteralPathdichotomy, as the latter is at least currently strictly about wildcards.SteveL-MSFT commentedon Oct 31, 2018
Michael Klement (@mklement0) the problem isn't that
\is treated aswildcard, but that the cmdlets apply path normalization first before using the path. So all\gets changed to/on non-Windows (and vice versa for Windows).Even:
fails as it tries to write to
/bar.txtmklement0 commentedon Oct 31, 2018
Understood, Steve Lee (@SteveL-MSFT).
My example commands showed how it should work once fixed, based on my interpretation of the conclusion reached in #6833 - did I misread that conclusion?
My point was that this escaping should work with both
-Pathand-LiteralPatharguments, as the latter distinction - at least so far - relates to wildcards only, and the\//issue is conceptually separate.After all, I shouldn't have to forgo wildcard matching just so I can get my
\chars. interpreted as-is.An aside re your example: If you use double quotes, you'll have to use two
`chars., because a single one is "eaten" by string parsing.SteveL-MSFT commentedon Oct 31, 2018
Michael Klement (@mklement0) ok, I see what you mean. Yes, if escaped properly, it should work with
-Pathas well.