Totally agree. We shouldn't have to Push-Location just to use this feature.

You could use Join-Path -Resolve for this:

PS> Join-Path $home\Downloads ../Documents -Resolve
C:\Users\Keith\Documents

This also has the benefit of correcting the directory sep char for the platform.

@rkeithhill I don't think that'll work for this particular problem. It appears that the -Resolve switch on Join-Path is only for checking whether the resulting joined path actually exists. At least on the surface, it doesn't appear to help with relative resolution. From the docs:

-Resolve
Indicates that this cmdlet should attempt to resolve the joined path from the current provider.

* If wildcards are used, the cmdlet returns all paths that match the joined path.
* If no wildcards are used, the cmdlet will error if the path does not exist.

This is my workaround:

function Resolve-RelativePath {
	[CmdletBinding()]
	param(
		[Parameter(Mandatory, ValueFromPipeline)]
		[string[]]$Path,
		[string]$ReferencePath = "."
	)
	begin{
		$ReferencePath = (Get-Item $ReferencePath).FullName
	}
	process {
		foreach ($pItem in $Path){
			$pItem = (Get-Item $pItem).FullName
			[System.IO.Path]::GetRelativePath($ReferencePath, $pItem)
		}
	}
}

This would help mitigate #10509 . Would love to see some traction on this, as it seems pretty simple.

What if we add new parameter for base path Resolve-Path -BasePath as optional for Relative parameter?

🎉This issue was addressed in #19358, which has now been successfully released as v7.4.0-preview.3.:tada:

Handy links:

• Release Notes