Closed Hashbrown777 closed 4 days ago
I agree that the docs should be amended to clarify that the literal aspect of the -LiteralPath
parameter only relates to not treating its arguments as a wildcard pattern, not also to not interpreting an argument-initial ~
(either standalone or if followed by \
or //
) as the home location of the provider underlying the current location (which is interpreted as such irrespective of whether you use -LiteralPath
or -Path
).
(I don't think that changing the current behavior to also treat ~
literally would be considered acceptable, as it is may break existing scripts.)
Note that, unlike in POSIX-compatible shells:
Neither interpretation (wildcard patterns, ~
) is a shell expansion, i.e. the interpretation is not performed by the PowerShell engine itself in a command-agnostic fashion; instead, the interpretation is provided by the targeted provider.
As such, whether a -LiteralPath
or -Path
argument is quoted or not is irrelevant.
@mklement0 that's interesting that it's not powershell doing it.. but the same systems using the other 'native' CLI do not have this issue (id est it is the shell expanding ~
)
If the [.net] provider cannot be amended, and the cmdlets wont be changed to escape ~
before handing over to it (to bring it in line with other shells..), it absolutely must be in all documentation (as it functions counter to non-pwsh expectations)
@mklement0 that's interesting that it's not powershell doing it
I think it is PowerShell doing it because there is nobody else doing it, the operating system does not do it. What I think @mklement0 is saying is it is not the command line variable expansion doing it, it is the PowerShell file system provider almost treating ~ as a logical drive.
I took it to mean it's .NET doing it, as pwsh would be using it to provide filesystem access, and the other CLI not utilising .NET is why 'nobody else is doing it'. But I could be wrong, I'd have to write some C# or something to check.
If you're right then this definitely falls closer to 'we should change this, not just document it' :/
I'd have to write some C# or something to check.
PSCmdlet.GetUnresolvedProviderPathFromPSPath does this translation, in my test case from "~/.ssh/known_hosts" to "C:\Users\rhubarb\.ssh\known_hosts".
Typically you use GetResolvedProviderPathFromPSPath for -Path and GetUnresolvedProviderPathFromPSPath for -LiteralPath.
So not the command line expansion. not the .NET runtime, it is the PowerShell file system provider.
This translation does other important things like give you the current location per thread, as current directory is a process wide thing.
I suggest making a doc issue to clarify the use of -LiteralPath
,https://github.com/MicrosoftDocs/PowerShell-Docs. (cc @sdwheeler). I will leave it up to working group to decide how to approach this, feels like a pretty niche case but definitely sympathize with the confusing messaging with "literal path"
GitHubThe official PowerShell documentation sources. Contribute to MicrosoftDocs/PowerShell-Docs development by creating an account on GitHub.
I'm not sure that this is unique to -LiteralPath
. The workaround for the OP is to qualify the path.
/home/sdwheeler> $pwd
Path
----
/home/sdwheeler
/home/sdwheeler> New-Item -Type Directory -name ~
Directory: /home/sdwheeler
UnixMode User Group LastWriteTime Size Name
-------- ---- ----- ------------- ---- ----
drwxr-xr-x sdwheeler sdwheeler 05/06/2024 13:37 4096 ~
/home/sdwheeler> cd ~
/home/sdwheeler> cd ./~
Path
----
/home/sdwheeler/~
Yes, the interpretation of a stand-alone ~
as a path or a ~/
-prefixed path as ~
referring to the provider's home location is unrelated to the -LiteralPath
/ -Path
distinction,
but the point is that it's reasonable to assume that if you use -LiteralPath
that ~
too will be treated literally, so adding a note to the docs would be helpful.
The docs have been updated.
Resolving as the current code behavior would be a breaking change and I do think some folks would be surprised if ~
didn't go home even for -literalpath
.
This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.
📣 Hey @Hashbrown777, how did we do? We would love to hear your feedback with the link below! 🗣️
🔗 https://aka.ms/PSRepoFeedback
Prerequisites
Steps to reproduce
I [personally] think
LiteralPath
should not be interpreting any special characters. However, if understandably this cannot be helped at this stage, tilde should be mentioned in the documentation.'./~'
can be used to rectify this if possible within your script, but it erodes trust in what else PowerShell is doing. The example usescd
, but this affects everything (Get-Item
,Remove-Item
, et cetera).Expected behavior
Actual behavior
Error details
Environment data
Visuals
No response