`-LiteralPath` still interprets `~` about powershell HOT 12 CLOSED

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.

from powershell.

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.

from powershell.

@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.

from powershell.

The docs have been updated.

from powershell.

@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)

from powershell.

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' :/

from powershell.

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"

GitHub

GitHub - MicrosoftDocs/PowerShell-Docs: The official PowerShell documentation sources

The official PowerShell documentation sources. Contribute to MicrosoftDocs/PowerShell-Docs development by creating an account on GitHub.

from powershell.

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/~

from powershell.

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.

from powershell.

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.

from powershell.

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.

from powershell.

📣 Hey @Hashbrown777, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms

from powershell.