Powershell: problem with set-location after passthru

Created on 7 Oct 2020  路  8Comments  路  Source: PowerShell/PowerShell

i use this command to set-location
Get-ChildItem | Out-GridView -PassThru |Set-Location
but in powershell go to
Microsoft.PowerShell.Core\FileSystem::~\Desktop
and this make some problem for example i want to open file explorer in this location but explorer open in quick access not in this location

PSVersion 7.0.3
PSEdition Core
GitCommitId 7.0.3
OS Microsoft Windows 10.0.19041
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0鈥
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Issue-Bug Resolution-Duplicate

Most helpful comment

That would involve changing and possibly breaking quite a few other cmdlets / use cases that work with the pspath/literalpath pipeline binding. For example, the Registry doesn't really have objects that have a FullName or similar property from memory that works quite the same way that filesystem objects do, they have a PSPath and then if you want anything else you're more or less left to construct it from pieces, which gets quite annoying.

This is as far as I ever got to fixing this, the proper "fix" is still not clear to me, there'a a fair bit of discussion in this old, unmerged PR: #9294

The other issue we've seen around this is #9293, which I guess this one is essentially a duplicate of. Might be more productive to continue discussion in that issue?

All 8 comments

Please share PSVersionTable as requested in the issue template.

get-item .. | select -expand fullname | set-location
Will work
get-item .. | set-location passes a directoryInfo object with a PSPath property, cmdlets usually prefer to use this rather name or full name, and we don't see it . For set-location it's a bit ugly, but it is still the same place.
Same thing on Win PowerShell 5.1 and on 7.0.3

It is seem dup #3307.

No, #3307 says "name" <> "fullname", but $x | cat uses PSPath so isn't affected.

This one is "Set-location accepts both path and literalpath, and literalpath / pspath takes predence"
So you can do

> Set-Location -LiteralPath (get-item .).pspath
>$Pwd   
Path
----
Microsoft.PowerShell.Core\FileSystem::C:\Users\James\Documents\Stuff

And connect to the PSProvider instead of the drive, which is counter intuitive. drive-less CD - for example
set-location Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT\
Is quite legal, and useful, though not very often . It would be possible to change which property was picked up by default.

That would involve changing and possibly breaking quite a few other cmdlets / use cases that work with the pspath/literalpath pipeline binding. For example, the Registry doesn't really have objects that have a FullName or similar property from memory that works quite the same way that filesystem objects do, they have a PSPath and then if you want anything else you're more or less left to construct it from pieces, which gets quite annoying.

This is as far as I ever got to fixing this, the proper "fix" is still not clear to me, there'a a fair bit of discussion in this old, unmerged PR: #9294

The other issue we've seen around this is #9293, which I guess this one is essentially a duplicate of. Might be more productive to continue discussion in that issue?

@vexx32 Yes I think you had the the right idea in #9294 - i.e. it's not something which should be changed generally; Strictly speaking set-location is doing the correct thing but it _feels_ wrong, and seems like a bug to the OP.

Aye. In the specific case of Set-Location I do think we should fix it as best we can, but I'm unsure of the best way to approach that at the moment.

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

Was this page helpful?
0 / 5 - 0 ratings