Questions[stty](server)

I am connecting to a Debian virtual machine using PuTTY, and every time I press the 0 (zero) key, the command line behaves as if I've pressed enter. Why might this be and how can I change it?

Perhaps also relevant: I'm connecting from Windows 10, using PuTTYtray, and have installed a custom keymap created using Microsoft Keyboard Layout Generator 1.4 (which leaves 0 alone but changes its shifted behaviour). The Debian machine is a DigitalOcean droplet. I've been using it for about a year and have never noticed anything like this.

Things I've tried:

• Pressing 0 in other applications -- normal behaviour
• Pressing 0 in other PuTTY sessions on other hosts -- normal behaviour
• Trying another shell (bash instead of zsh) -- 0 still acts as enter
• Disconnecting and reconnecting -- same behaviour
• Keypad 0 -- also acts as enter
• Shift and 0 -- works as expected (> on my keyboard)
• Connecting to the problem host via another (Ubuntu) host -- 0 acts normally
• Connecting to another host via the problem host -- even weirder! -- 0 acts as if I had pressed 0 THEN enter
• GNU screen -- 0 still acts as enter

Any suggestions?

I'm using stty susp ^- in a user's .bashrc shell in an attempt at preventing users from using CTRL+Z to background a process.

The reason behind this, is that we have a number of users who are used to using Oracle SQLPlus on VMS, and the default editor uses CTRL+Z to save and quit the editor. CTRL+Z on Linux obviously has a completely different action, and manages to completely baffle our users as they instinctively hit CTRL+Z.

Whilst stty susp ^- seems to work with some commands (e.g. top), it doesn't work when I really need it to, i.e. in editors such as nano or vim.

Can anyone suggest how I might achieve this?

Edit: I don't need to use bash, so an alternative shell that doesn't support job control should suffice (assuming such a shell exists).

I telnet to an HP switch from my (xterm|gnome-terminal). Exit telnet. That breaks the behaviour of the terminal. (If you don't have a HP switch to telnet to, one can cat this file in a terminal instead).

Now type a very long command (more than one line, and see that the second line doesn't wrap down to the next line, but "stays in the current line". Which makes it impossible to edit prior commands or use the terminal for anything longer than one line.

See that cat filewithlonglines.txt or git log -p only shows the first 80 chars of lines longer than 80 chars.

reset doesn't work. stty -g > stty.works, run telnet, stty $(stty.works) restores changed stty settings, but behaviour is still broken.

I have to close the terminal and start a new one. :-(

What can I do besides reset and stty save/restore to fix my broken terminals after a telnet?

EDIT: I've discovered that if I use screen like in one of these commands:

screen bash -c "cat hptelnet.escape ; bash"

or

screen telnet hpswitch

Then my terminal still works properly when screen exits. So a workaround is to put screen in front of the command that messes up my terminal, but I'd still like to know how to recover a terminal that already has been messed up...

Probably a newby's question - I saw the command stty erase ^H in one of our log-in script and wanted to know what it does. Does it work on TCSH? or is it only applicable to KSH?

I have a virtualization server to which I connect over ssh. If I now change the size of the window it will automatically propagate to the server. It's most easily seen using stty -a, checking the columns and row values.

I then use virsh console to connect to the serial interface on a KVM based virtual machine. When I now change the size of the window it does not propagate to the virtual server. This is most easily seen by checking stty -a, which is not updated on the virtual machine when I change window size. This means that line breaks does not work correctly in the terminal and any application that relies on window size for formatting (emacs, man, etc) gets messed up unless the window size on the client matches the default size on the server.

A workaround is to manually set the window size to match the client window using stty, but I wonder if there is any way to get this information to propagate and set the window size in the virtual machine automatically.