Shell dropping every other character of input

Question

I manage software on a bunch of RHEL 6.10 VMs, typically either as a service account or root using sudo -i. Periodically, my shell starts dropping every other character. For example, if I type

cd /usr/local

what actually shows up is

d/s/oa

It's not just cosmetic; if I press enter there, I get

-bash: d/s/oa: No such file or directory

The only solution I've found is to log out of the sudo session (with ^D^D because the first one is ignored) and log back in. This leads me to believe it's not an issue with my terminal or ssh client, but just in case, here's the full stack:

Human > Keyboard > Windows 10 > MobaXTerm > WSL OpenSuse > tmux > ssh > bash > sudo

Obviously, I could try removing tmux from the stack, or WSL altogether, but it would cramp my workflow and be difficult to troubleshoot, as it's an intermittent issue I only encounter about once a week.

What could be causing this?

Answer 1

I have this experience using Putty, RHEL 8, and XMing.

I forget to add XMing before the Putty session. I found that reversing it and doing XMing first then Putty solves it.

Or if I have run XMing then Putty to a server, to then jump via ssh without XAUTH verification, I press CTRL -C a few times.

XMing or VCXSRV are two tools to export display.

Either of these appear to clean the guck from the pipes and I type without issue. Is your experience similar?

Answer 2

I have similar keyboard problems with a diferent (and longer) stack of communication programs, like getting invisible characters or rare codes, but I think they are caused by me inadvertently pressing a key combination that changes the terminal functions.

I really don't have time, as you say, for diving in the term definitions looking for which keys could provoke the change, like if pressing a+b+c during a furious typing session could cause the keyboard to send a XOFF ^S command to the remote terminal that stops sending output or something like that. We need a key capturing program to store the keys pressed and another in the remote for getting the received ones to troubleshooting. Also, as there are several programs involved, it is difficult to blame one or other of them.

In the mean time, sometimes a stty sane or reset command in the terminal solved this for me (because of these cases I think is a oscure key term command unknowingly causing the problem); other times I had to restart the shell as you do or even reconnect some portion of the stack.

Answer 3

Try using the lsof command as suggested by roaima in a comment to your question. Here is an example that show how bash and the lsof command both have file descriptor (FD) 0 (=stdin) opened, but neither of them are reading from it at the time of command execution. You should look for other processes that have file descriptor 0 open. Kill them one by one until the issue goes away. Not bash obviously, unless you see FD 0 opened multiple times by bash.

$ lsof /dev/pts/8
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
bash    15190 thisusr    0u   CHR  136,8      0t0   11 /dev/pts/8
bash    15190 thisusr    1u   CHR  136,8      0t0   11 /dev/pts/8
bash    15190 thisusr    2u   CHR  136,8      0t0   11 /dev/pts/8
bash    15190 thisusr  255u   CHR  136,8      0t0   11 /dev/pts/8
lsof    19576 thisusr    0u   CHR  136,8      0t0   11 /dev/pts/8
lsof    19576 thisusr    1u   CHR  136,8      0t0   11 /dev/pts/8
lsof    19576 thisusr    2u   CHR  136,8      0t0   11 /dev/pts/8