Proposal: Resolve-Path should return a un-ambiguous single path

[Jaykul]

I think that Resolve-Path should normalize the path. Do we need a separate cmdlet for that?

Currently, it seems to just pass through whatever you feed it:

I ♥ PS> Push-Location C:\
I ♥ PS> Resolve-Path \Windows | % ToString
\Windows

I ♥ PS> Push-Location FILESYSTEM::C:\
I ♥ PS> Resolve-Path C:\Windows | % ToString
C:\Windows

I ♥ PS> Resolve-Path FileSystem::C:\Windows | % ToString
FileSystem::C:\Windows

I ♥ PS> Resolve-Path Microsoft.PowerShell.Core\FileSystem::C:\Windows | % ToString
Microsoft.PowerShell.Core\FileSystem::C:\Windows

I ♥ PS> Resolve-Path Microsoft.PowerShell.Core\FILESYSTEM::\WINDOWS | % ToString
Microsoft.PowerShell.Core\FILESYSTEM::\WINDOWS

How can I test if two paths refer to the same location?

[FriedrichWeinmann]

Well, I don't know about convenient but you can do that using the Provider & ProviderPath properties:

$r1 = Resolve-Path C:\Windows
$r2 = Resolve-Path Microsoft.PowerShell.Core\FileSystem::C:\Windows
($r1.ProviderPath -eq $r2.ProviderPath) -and ($r1.Provider -eq $r2.Provider)

Converting straight to string risks loosing quite a bit of information.
On the other hand, most parameters for paths happen to be string, causing that conversion to happen right there.

[BrucePay]

Resolve-Path resolves all of the PowerShell specific stuff (drives, wildcards, etc.) into a Path object as @FriedrichWeinmann points out. For example:

PS[1] (120) > Resolve-Path zork:\ | fl

Drive        : zork
Provider     : Microsoft.PowerShell.Core\FileSystem
ProviderPath : C:\windows\
Path         : zork:\

The ProviderPath property is what you probably want most of the time (like 99.9999% of the time) but the default ToString() on this object appears to return the original path you gave it which seems pretty useless.

The useful bit for Resolve-Path is the resolution of PowerShell path artifacts (drives, wildcards, path separators) into a canonical provider-specific path. But to do this, the target path must exist so. This means that you can't use it to normalize paths that don't exist which is annoying.

I'm not sure if we should try fixing this command or create new filesystem-specific path commands (including handling things like getting the basename or extension of a file, etc.)

[Jaykul]

You'd think so @FriedrichWeinmann, yes, but there's some ambiguity around what happens based on your current location:

Set-Location C:\
$r3 = Resolve-Path FileSystem::\Windows
$r3 | fl * 

Drive        :                                     
Provider     : Microsoft.PowerShell.Core\FileSystem
ProviderPath : \Windows                            
Path         : FileSystem::\Windows                               

You'll note that it can't be bothered to tell me which drive that path resolved to? Somehow, it "knows" (I guess that if no drive is specified, it uses the first one?). This path is kind-of a major problem for me, but that's not this issue.

Do you think we could call the drive not being set (and being missing from the provider path) a bug?

Personally, I think the ToString() implementation should have been Provider + "::" + ProviderPath which (except for the drive bug) would be un-ambigous (except for the possibility of having SUBST style overlapping drive letters) but I realize it's probably too late to change that.

What if we fix the drive bug, and add a FullyQualifiedPath property?

@BrucePay I wouldn't argue against adding some more "FileSystem specific" path commands, in general. Especially for new users, it would probably be useful to expose a few more of the static methods of System.IO.Path (even if people like me are just going to tell them it would be faster to use the static methods) 😉 I know I use ChangeExtension and GetFileNameWithoutExtension often...

[FriedrichWeinmann]

Do you think we could call the drive not being set (and being missing from the provider path) a bug?

Agreed - the missing drive is an issue (and I do think it qualifies as bug).

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.