I found shreyansp's solution to be the most (but not quite) satisfactory one :)
Here's my attempt on improving that (of course YMMV). Hope this may be of use to those looking for a solution :)
My solution behaves as follows:
- caffeine sends to Windows an appropriate Virtual-Key Code which:
- prevents Windows from going to sleep or idle
- does not otherwise generate any side-effects on Windows neither alone nor in combination (no Ctrl, Shift, Alt, Alt-Gr, Win, F1-F5, F10, etc.)
- either is not sent to Putty or is ignored by Putty
TL;DR: My solution is applied between steps 2 and 3 (see below) with the -key:0E
caffeine param:
Exit Caffeine & re-launch it with:
caffeine.exe 5 -key:0E
(for easy testing)
caffeine.exe 50 -key:0E
(for a mandatory screen saver set at 1 minute)
- Launch
read
program on the remote host and watch how no keystrokes are received every 5 or 50 seconds.
- Exit
read
with Ctrl+C
Shreyansp proposed a solution where a fix would be applied between steps 5 and 10 (see below).
The side-effect of that (on my config) was that, with each keystroke that putty forwarded from caffeine to the remote host:
- it triggered a 'Reset scrollbar on keypress' (setting on
Putty/Window page)
which I would normally want, but only when I (the human) is pressing the key but not regularly by caffeine :)
- readline/bash translated version of it (from
'"\e[28~"'
to '""'
(blank key ?) caused the remote session interaction to hang for several seconds
In order to easily test the above, exit Caffeine & re-launch it with 5 seconds interval and Virtual-Key Code 07:
caffeine.exe 5 -key:07
- Launch
read
program on the remote host and watch how keystrokes are received every 5 or 50 seconds.
- Exit
read
with Ctrl+C
The keystroke 'pipeline', as I understand it:
- Caffeine sends a Virtual-Key Code to Windows
- Windows sends that Virtual-Key Code to Putty
- Putty does some 'translations'/'mappings' based on some session settings in:
- Putty sends the 'translated'/'mapped' key code to the remote host
- On the remote host, the 'terminal' program (e.g:
$TERM=xterm
, vt100
, vt102
, vt220
, etc.) translates from the 'line protocol' into key codes.
- the readline library does some translations/mappings based on
~/.inputrc
- readline sends the Key Code to bash
- bash does some translations/mappings based on
~/.bashrc
(based on the builtin bind command)
- bash or readline (not sure which one) sends the translated Key Code to nano (my text editor)
- This pipeline can get even longer by adding the
screen
program (which includes a $TERM=screen
for step 5. and loops back again at step 6. to 10.)
Note: Once it gets to step 4., it becomes very difficult to precisely control the different layers of 'translations'/'mappings'. I would recommend avoiding that if you can.
Background:
I used caffeine.exe -key:07
for years before having to deal with a pfsense 2.3.3-RELEASE-p1 (based on FreeBSD 10.3-RELEASE).
Then, caffeine.exe -key:07
was received on the other side as ^[[28~
... which seems to be mapped to Ctrl+^
(Set Mark) in Nano.
This was quite annoying (imagine someone pressing and keeping Shift Key while you move the text caret around in Notepad).
Previously, I did numerous customizations in Putty Settings, ~/.tcshrc
, ~/.inputrc
, ~/.bashrc
, ~/.nanorc
, ~/.screenrc
to get what I consider basic functionality (Backspace
, Delete
, Home
, End
, PgUp
, PgDown
, Ctrl+Left
, Ctrl+Right
, Numpad 0-9
, Numpad ./*-+
) working consistently between bash/nano/screen.
Once I discovered this caffeine.exe -key:07
'bug', I didn't want to retrace that all over again :)
Tested on:
Windows 8.1 64-bit Enterprise (6.3.9600) / Putty 0.66 / pfsense 2.3.3-RELEASE-p1 (based on FreeBSD 10.3-RELEASE) / bash 4.4.12-release / nano 2.7.3 / screen 4.04.00
References:
Does your computer also do this if you leave open a random program on your host for a few hours, like notepad? – cutrightjm – 2014-01-29T06:08:45.847
@ekaj No, only in PuTTY. And aparantly PuTTY based programs like MobaXterm (I downloaded the portable version to test) EDIT: only during an SSH session in Moba – Zachary Polikarpus – 2014-01-29T06:39:30.480
Hmm. Are you sure it's not pretty close to periodic, like always 55-65 seconds while putty is entirely idle? If it is, it might be a "keep-alive" activity, either from the server end or maybe putty. Have a look at things found under a search "alive" in putty help. Maybe these will be helpful: http://superuser.com/questions/94436/how-to-configure-putty-so-that-home-end-pgup-pgdn-work-properly-in-bash http://unix.stackexchange.com/questions/6105/what-causes-a-ssh-interruption/6107#6107
– mgkrebbs – 2014-01-29T08:54:32.577@mgkrebbs Sometimes it seems periodic, but it occasionally won't occur for about 5 to 6 minutes, then go right back to seeming periodic. Regarding the keep-alive idea, if that is the case, It seems to be isolated to the client side because if I start an ssh session from a linux machine in native terminal, all is well. I did see that first link when I was asking the question, and tried changing the terminal type to "linux", but that didn't seem to make any noticable difference. – Zachary Polikarpus – 2014-01-29T13:10:08.393
I've been experiencing this issue as well. It shows up when I'm using Putty, Kitty and even MobaXterm. – Attilah – 2014-04-27T07:14:04.523
What do you have for
– harrymc – 2014-04-27T10:21:49.913echo $TERM
? Also in this thread the solution was to set PuTTY window size to 95 columns.What OS are you connecting to...any other info about the remote machine you can provide? – Jared – 2014-04-29T15:50:43.047
@Attilah, any chance you can get the same odd characters when using special buttons on your mouse? Like the scroll wheel? Or: does it still happen if you unplug the mouse? – Arjan – 2014-05-03T12:11:55.760
Related: Why Putty inserting ~ into my Fedora bash shell, which nicely explains why one might only see the
– Arjan – 2014-05-03T12:13:44.570~
(and hear a beeb) when actually something like\e[3~
is sent.