New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
-LiteralPath
still interprets ~
#21555
Comments
I agree that the docs should be amended to clarify that the literal aspect of the (I don't think that changing the current behavior to also treat Note that, unlike in POSIX-compatible shells:
|
@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 |
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' :/ |
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
|
I'm not sure that this is unique to
|
Yes, the interpretation of a stand-alone |
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 |
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 uses
cd
, but this affects everything (Get-Item
,Remove-Item
, et cetera).Expected behavior
Actual behavior
Error details
Environment data
Visuals
No response
The text was updated successfully, but these errors were encountered: