Feature request: open a local Explorer window from remote command line

[juj]

Here is a bit exotic but interesting use case that came up recently.

On local Windows cmd.exe command prompt, it is possible to open an Explorer window to the current working directory by typing explorer . in the directory. This allows a nice "duality" of traversing directories in cmd prompt vs in an Explorer window on the local computer.

There exists a really cool project at https://github.com/Foreveryone-cz/win-sshfs which allows one to map a directory tree on a remote SSH server as a local Windows Explorer drive mount point. E.g. local drive F:\ could point to a remote directory ssh://user@remoteserver:~/path/to/expose. This integrates Windows Explorer with a remote SSH remote server.

PuTTY allows the other side of this, the remote command prompt. What I would like to do with PuTTY is to be able to type explorer . (or a similar command) on a remote linux SSH server, which would cause the sshfs mounted directory corresponding to the current working directory in PuTTY terminal to be opened in local Windows Explorer.

E.g. if one is logged in via PuTTY to a remote SSH server and current working directory is ~/example/dir and ~/ was mounted as drive F:\ in Explorer via win-sshfs, typing explorer . in PuTTY command prompt would open a local Explorer window in directory F:\example\dir.

This would give the same kind of duality of navigating directories in PuTTY command prompt vs navigating them in Windows Explorer.

Any thoughts if this is something that would be feasible to implement?

[juj]

To keep such an integration simple, it would probably be most sensible if PuTTY did not know anything about win-sshfs, but offering a terminal command along the lines of putty-open-folder F:/example/dir that one could type on a remote server, which PuTTY would intercept, and then invoke the local process explorer F:\example\dir would be enough. After that it would be possible to bash script the directory mount point mappings appropriately.

[FauxFaux]

This would require similar functionality to #262: a sidechannel for backtalk from a command to the terminal.

Sounding more tempting...