[jdonahue]

I think it would be neat if SSH provided an API or a set of special characters so that the remote shell could tell SSH to switch back and forth between remote and local echo. For example, bash could tell SSH to begin local echo mode after it finishes printing the prompt, and end local echo mode when the user enters a key sequence that requires remote processing, like Tab or Return. vim could enter local echo mode when the user enters insert mode and leave when the user presses the Esc or Return, etc.

Perhaps this extra complexity would lead to all sorts of strange bugs though.

[simias]

There already exists such an API at the TTY level (see man 4 termios). You can switch between so called "canonical" mode where the input is buffered by lines or non-canonical to get the input byte by byte without waiting. You can also switch echo on and off among other things.

I don't think ssh sends that back to the client terminal though, but I must say I'm not really sure how that's handled. On one hand I'd like to know better how unix TTYs work, but on the other I value my sanity so I'm probably not looking back into those just now :).

[akjj]

This is right, but the canonical/non-canonical distinction is all or nothing. Bash echos most characters, but it needs to treat a handful, like tab, up, and down, specially so it (or readline probably) puts the terminal in non-buffered mode and ends up echoing the normal characters. I read the GP as suggesting that there should be a way for bash to indicate which characters were "normal" and should be buffered and echoed and which it wants to see immediately. It's an interesting idea, but of course such a mechanism would require coordination between the kernel's terminal interface, bash/readline, and ssh in order to get a marginal improvement in network efficiency.

[jdonahue]

Ah, providing it at the terminal level does make more sense (that was probably obvious to anyone with any familiarity with the basics of Unix terminals, sorry), and now that I hear it I'm not surprised it already exists :)

In that case, I guess this functionality would be implemented similarly to the example you mentioned of stopping the client from sending every keystroke at a password prompt, right? It seems like it would be strange for ssh to send the 'toggle echo' signals to the client, but not the 'toggle canonical mode' signals (which the client could also handle in a useful way).