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