The Problem

I've worked exclusively in Windows. I can handle that.

I've worked exclusively in DOS (a long time ago!). I can handle that.

I've worked exclusively in Unix. I can handle that.

Right now, I am developing a command-line (python) application on a Windows machine, testing it in a DOS box (i.e. Windows' Command prompt), and then deploying it to Linux, and running it with PuTTY.

I cannot handle that.

My productivity drops dramatically when CTRL-C cuts in one window (Windows) and kills the process in another (DOS, Linux).

My productivity drops dramatically when Enter copies the selection in one window (DOS), and deletes the selection in another (Windows), and runs the current half-edited command in the third (PuTTY).

My productivity drops dramatically when I cannot hit Undo, Home or End.

The Solution I am Seeking

An SSH/Bash command-line client that runs on Windows and, to the extent possible, uses all the standard Windows shortcuts (Cut, Copy, Paste, Undo, Home, End, Insert, Shift-Arrows, etc.) work on a bash command line. Bonus points if it puts the cursor between letters, rather than on them. Plus, an equivalent DOS command-line drop-in that runs on Windows, and provides the same interface.

I appreciate there may need to be special buttons to actually transfer CTRL codes (like CTRL-C) through in the cases I need them.

I suspect the SSH client will need to be specific to a shell (so it knows when it is at the command prompt, and when it is inside a running app.)

I know there are many SSH clients, but I am looking for advice for a particular need. PuTTY feels like an escape route for Unix programmers stuck on Windows. I am the opposite.

Can anyone recommend one (or maybe a combination of an SSH client and an Command-Line replacement)?

Update: After seeing the early answers here, I turned my requirements into a blog article, which may give more background in the direction I am looking.

5 Answers 5


for terminal work i use 'mintty' which can be used as part of the 'cygwin' package. then i obviously run a "real" shell (zsh in my case), though powershell is not that bad (the bad part is really the terminal windows provides. it is horrible).

  • you can launch cmd.exe from inside bash/zsh
  • you have ssh in cygwin
  • you can change the way the cursor looks in mintty (so it appears as a | instead of a block)
  • you can mark text just as in xterm and with ctrl+leftclick you can launch an appropriate application on that marked text (lets say you mark http://superuser.com and ctrl+leftclick -> a browser fires up, in case you selected C:\Windows the explorer fires up etc)

the only other way to do it is to develop directly on the remote server through a ssh-session, using a decent editor (vim comes to mind).

  • Powershell has a more powerful language, but the editor is just as bad as Command Shell. I do use a remote editor occasionally (emacs rather than vim, but let's not go there) and it just makes the problem worse. Most of my editing is done in dozens of other apps which accept Windows short-cuts (such as the browser I am using now). Sudden CTRL+V to paste makes it emacs page-down. :-( Jun 9, 2010 at 6:35
  • what about "shift+insert" ?
    – akira
    Jun 9, 2010 at 7:22
  • @Akira, I've been reading the mintty manual, to see if I should accept this answer. I saw the Shift+Insert, and maybe 15 years ago, when I was still using that shortcut, I would have been satisfied with it, but these days it would probably be equally frustrating as PuTTY. I might give it a try anyway (and I have +1'd your answer). Jun 9, 2010 at 15:48
  • @oddthinking: shift+insert .. feed that into emacs? so at least that pain goes away?
    – akira
    Jun 9, 2010 at 16:12
  • @akira, the difference between (terminal-based emacs) look-and-feel and the Windows look-and-feel is more than a few key-bindings. They have fundamental differences in the way they treat buffers and text. In any case, the command-line is my concern (unless you are suggesting running the command line through emacs?) Maybe I should be writing my own solution. It doesn't sound too hard. (Famous last words!) Jun 10, 2010 at 1:23

This is difficult, due to Unix conventions and the split of responsibilities for input handling between the terminal, terminal driver, and shell. But there are some things you can do.

As already pointed out, using mintty, Ctrl+Insert and Shift+Insert copy to and paste from the Windows clipboard. The terminal can't Cut, because it doesn't have control over the shell's line buffer. Those shortcuts came from IBM's Common User Access (CUA) standard. They first appeared in DOS apps and have been in Windows from the start.

Ctrl+X/C/V, meanwhile, came from the Mac. Arguably more convenient, but the big problem with using those in a terminal, of course, is that Ctrl+C is the interrupt key, with lots of applications using it for things like Cancel as well. Also, Ctrl+V is the standard key for 'quoted-insert' in a shell, which removes any special meaning from the next keypress, and Ctrl+X is the first key for many two-step shortcuts.

I don't think there's any way to use Shift+arrow for marking text in Bash. Instead, you press Ctrl+Space to set the "mark", and then if you move the cursor, the text between the mark and the cursor is selected. Unfortunately you don't actually get to see the selection (called "region"), so you have to remember where you put the mark.

(Zsh works the same, but unlike Bash, it does highlight the selection. Enhancement issue 84 for mintty requests the ability to select text using the keyboard at the terminal level; such a feature would likely use Shift+arrow.)

Now the default shortcuts for operating on the "region" are emacs ones, but you can change them to Mac style, by putting the following into a file called .inputrc in your home directory. (Read all about .inputrc in Bash's man)

"\C-x": kill-region
"\C-c": copy-region-as-kill
"\C-v": yank

But hang on, what about the special meaning of those keys? Well, you've just lost all the Ctrl+X two-step shortcuts, so you'd have to rebind the ones you actually need yourself. Meanwhile, Ctrl+V's function could go to Ctrl+Q:

"\C-q": quoted-insert

That leaves the all-important Ctrl+C. That's actually handled by the terminal driver, so you'll need to move it somewhere else using 'stty'. Mintty has a control sequence that allows the Escape keycode to be changed such that it can be used as the interrupt key. Putting this into your Bash startup script will do it:

echo $'\e[7728h'
stty intr ^\

Mintty's keycodes for various special keys also allow some other stty settings to be changed to Windows style:

  • swtch ^] susp ^] - Pause instead of Ctrl+Z for sleeping a process
  • eof ^^ - Ctrl+Enter instead Ctrl+D for end of file
  • werase ^_ - Ctrl+Backspace instead of Ctrl+W for erasing a word
  • lnext ^q - Ctrl+Q instead of Ctrl+V for literal insert of the next character

You might also want to remove the terminal driver shortcuts for stopping (^S) and starting (^Q) output, which aren't really much use but which are quite capable of causing confusion:

stty start - stop -

Back to .inputrc, there's a bunch of Windows-style key bindings to be had there:

# Ctrl+Left/Right to move by whole words
"\e[1;5C": forward-word
"\e[1;5D": backward-word

# Ctrl+Backspace/Delete to delete whole words
"\e[3;5~": kill-word
"\C-_": backward-kill-word

# Ctrl+Shift+Backspace/Delete to delete to start/end of the line
"\e[3;6~": kill-line
"\xC2\x9F": backward-kill-line

# Alt-Backspace and Ctrl+Z for undo
"\e\d": undo

Finally, you might find the following shortcuts useful as well. They look for a line in the history that starts the same as your current one:

# Ctrl-Up/Down for searching command history
"\e[1;5A": history-search-backward
"\e[1;5B": history-search-forward
  • Thanks, ak2. These examples are all about trying to make the shell itself act like Windows, which I regard pretty much as a lost cause. You have described a number of hurdles to jump over that I hadn't even considered, but it just goes to reinforce my view that this is the wrong way to achieve consistency. Instead, I am looking for a Windows application that allows editing of a Windows-like text-box, and then sends the result through to the terminal. Jun 25, 2010 at 10:28
  • I don't think it'd be impossible to make a shell's line editor behave like Windows and integrate with the Windows clipboard. Using zsh's highly configurable line editor and Cygwin's /dev/clipboard device, it might even be possible without hacking the actual shell. It certainly is a fair amount of work though, as is your idea of doing the line editing on the terminal side, unless of course there is such a terminal app already. The steps here, meanwile, while only offering a partial solution, have the considerable advantage that you could use them today.
    – ak2
    Jun 25, 2010 at 12:09

I think Cygwin does what you want... but I haven't used it in a few years. I'll actually install it right now to see how it fairs. It is somewhat overkill to be used just for an ssh client though.

  • Cygwin tries to make a DOS shell feel like a Unix shell. I am trying to make a Unix shell and a DOS shell feel like a Windows app. Jun 9, 2010 at 6:30
  • @Oddthinking Ah tricky...
    – James T
    Jun 9, 2010 at 6:52

ok, another way of addressing your problem:

editing the files you have to edit in a local editor and by writing them to "disk" you transfer them back to the server.


  • vim can do this via the netrw-plugin (which is part of the standard distribution now, iirc)
  • emacs seems to support this via tramp, but it also seems to have small issues.
  • setup a ssh-tunnel to a samba-share on the remote machine to mount it locally
  • try out expanddrive ("mounts sftp to your explorer")
  • try out sshfs for windows via dokan-sshfs.
  • Still solving the wrong problem I am afraid. I transfer the files through Mercurial over SSH. I could equally use one of the above suggestions. Either way, once the files are transferred, (a) I want to run them, and (b) I want to cut-and-paste snippets of the output. That's when the problems start - I need a command-line terminal window. And I would like one that supports Windows L&F. Jun 11, 2010 at 8:17

The most compatible bash I've found for Windows is GIT Bash and its much lighter than cygwin. Some commands need aliasing to use wintty though - for example I found that the az cli needs this with -Xallow-non-tty set while others like node and packer don't need this switch

  • You could also combine this with ConEmu to have a more cohesive experience across shells
    – JW0914
    Jan 3, 2020 at 14:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .