Powershell: get-location,set-location should support '.lnk' filetypes

[qt3m45su0najc7]

Link shortcuts to folders are not currently supported by set-location. The enhancement request is to support these file types for get-location, set-location, and querying the lnk file for what it references.

[kvprasoon]

Yourself know its not a Directory , and .lnks are not locations/directories/containers. Mentioned cmdlets are designed to work on Directories with different providers and not on Files.

@mklement0 Do you see any use case for this ?

[qt3m45su0najc7]

@kvpraseoon, 'lnk' files can point to files or folder.

[kvprasoon]

I think are expecting a redirection approach. But still .lnk is treated as a file and not sure about the feasibility of addressing this. Let see comments from others.

[mklement0]

The FileSystem provider's cmdlets such as *-Location and *-*Item operate only on actual _filesystem features_.

By contrast, *.lnk (and .url) files are a feature of the Windows (GUI) shell, whereas from a filesystem perspective they are simply _files_ - the filesystem knows nothing about such files' _contents_, which is where the shortcut target information is stored.

Contrast this with _symlinks_ (also junctions, mount points, and hard links) which are indeed filesystem features.

---

It would definitely be handy to have a PowerShell-idiomatic way to query *.lnk / *.url files, but I'm not sure direct support in Get-Location / Set-Location is the right place for it:

• A .lnk file may point to an _executable file_, which would make its use pointless with *-Location.

• Selectively adding non-filesystem features to just the *-Location cmdlets would introduce an inconsistency with the other cmdlets.

Perhaps the better solution is to introduce dedicated cmdlets for querying / creating / updating shortcut files.

For instance, instead of the currently awkward (note the need to pass a _full_ path, because the shell's idea of the current directory differs):

Set-Location ((New-Object -ComObject WScript.Shell).CreateShortcut("$pwd\some.lnk")).TargetPath

a potential Get-ShortcutFile cmdlet could enable something like:

Set-Location (Get-ShortcutFile some.lnk).TargetPath

[qt3m45su0najc7]

Hi @mklement0 Thank you. Thoughtfully considered. For me, even the final proposal is stall a little awkward for me. I was hoping for an 'objects that act (transparently) like folders should be addressed uniformly' solution. I think the utility should be able to introspect and determine that applying .targetpath, or any other hint like ornamentation, is needed rather than the developer.

[mklement0]

@qt3m45su0najc7:

While it would definitely be more convenient if Set-Location directly supported *.lnk files, I think it's better to keep the realms separate, not least because the overlap is imperfect: shortcut files represent not _just_ directories / files, and integrating a _subset_ of their features into the filesystem cmdlets invites conceptual confusion.

For instance, while a *.lnk file passed to Set-Location can only be sensibly interpreted as wanting to use that shortcut file's _target path_, use of *lnk files with Get-Item / Get-ChildItem would require disambiguation: are you targeting the *.lnk file itself or its target?

Independently, I think *-ShortcutFile cmdlets would be a useful addition.

[qt3m45su0najc7]

@mklement0 , Doesn't new-item have that kind of ambiguity? Do you want a new file or a folder? Isn't it resolved by -parameter (-itemtype)? Couldn't the same approach be applied?
Just posing the questions. I am simply playing the amicus cruaie, not the arbiter.

[mklement0]

New-Item, in the context of the FileSystem provider, defaults to item type _file_ and requires you to explicitly indicate if you want the _other_ foundational type of filesystem object - a _directory_ (folder) - or an indirection entity targeting either foundational type, such as a symlink.

The need to choose arises out of there being two foundational item types in filesystems, but note how the choices are limited to filesystem types _in the abstract_, irrespective of their (future) _content_.

Similarly, you have the -File and -Directory switches for Get-ChildItem to limit matching to either foundational type.

Note how you cannot do New-Item -Type WordDocument, for instance; that is, you can't create a new file with _specific content_, which is what creating a shortcut file (.lnk / .url) would require.

The Windows shell is a separate world built _on top of_ filesystem functionality - blending the two makes for a conceptual blur, and is also problematic from a cross-platform perspective.