PuTTY wish drag-drop-to-cwd

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Pre-release · Snapshot | Docs | Changes | Wishlist

summary: Drag and drop support (the hard version)
class: wish: This is a request for an enhancement.
difficulty: mayhem: Probably impossible
priority: low: We aren't sure whether to fix this or not.

drag-drop suggests, among other UI possibilities, the idea that dragging and dropping a file into a PuTTY SSH terminal window from the Windows Explorer should automatically SFTP it to the server via a spare SSH channel.

When users have asked for this, one particular request they've often made is that the file should be dropped into the current directory of the remote shell, so that you'd have it instantly available in the directory your prompt was sitting in anyway, and not have to go and fish it out of some standard designated uploads directory.

That, unfortunately, is not even feasible in theory, because there's no reliable way for PuTTY to determine what the currect directory of the remote shell is.

There are lots of ways to do it unreliably, or via setup from the user. You could imagine, for example, parsing the user's shell prompt to extract the cwd from it – but not all users put their cwd in their shell prompt, and the ones who do often format it differently. And even telling what is a shell prompt and what is not, from just a terminal data stream, needs more human interpretation than you'd guess. At best you might make this work, ish, most of the time, for a shell account that uses some fixed prompt format, say the default one in a clean Ubuntu login account.

More ambitiously, we could define some additional terminal escape sequence that is used by the shell to communicate its cwd (or rather, to communicate its preferred upload directory), and if a user wanted this feature, they'd have to set up some shell configuration that emitted that sequence every time the cwd changed. But the number of ways that could go wrong, from subshells of a different type to security hazards if the wrong server-side process was able to emit that sequence, don't bear thinking about.

So this one goes in at Mayhem difficulty. It's just not feasible.


If you want to comment on this web site, see the Feedback page.
Audit trail for this wish.
(last revision of this bug record was at 2021-05-02 11:23:46 +0100)