Kitz Forum
Computer Software => Linux => Topic started by: Weaver on August 06, 2019, 11:10:21 PM
-
When I run ‘screen’ I get garbage sometimes appearing on the display when I press the arrow keys on the keyboard and so up-arrow etc and Ctrl-A do not work as expected. It looks as if some code somewhere is either generating escape sequences VT-100 style when it did not do so before, or the esc sequences are being produced and some code is receiving them but is not recognising them for what they are.
I tried adding some switches with "screen -O -U" is that what I should be doing? If that is the answer, then it is not persisting, as the problem keeps on coming back.
If I hit Ctrl-D to get out, then I get normal arrow key handling behaviour back again.
-
When I run ‘screen’ I get garbage sometimes appearing on the display when I press the arrow keys on the keyboard and so up-arrow etc and Ctrl-A do not work as expected. It looks as if some code somewhere is either generating escape sequences VT-100 style when it did not do so before, or the esc sequences are being produced and some code is receiving them but is not recognising them for what they are.
I often use screen when remotely administering my RaspberryPis over SSH. Arrow keys work normally here. Up and down show previous commands. Left and right traverse the input line.
Ctrl-a is used here to send a keystroke to the screen program itself rather than the program running in the screen.
I tried adding some switches with "screen -O -U" is that what I should be doing? If that is the answer, then it is not persisting, as the problem keeps on coming back.
No experience here with command line switches as they have not been needed.
If I hit Ctrl-D to get out, then I get normal arrow key handling behaviour back again.
Ctrl-a <d> detaches me from the screen
PS The RaspberryPis are all running Raspbian.
-
Sometimes the arrow keys work fine for me as for MartinGoose, then the thing gets into a particular mode where it is broken until I quit out of that shell, to another earlier one.
-
Sometimes the arrow keys work fine for me as for MartinGoose, then the thing gets into a particular mode where it is broken until I quit out of that shell, to another earlier one.
Do you detach from the first instance of screen before starting a second one?
-
No, I don’t think so. Is that perhaps where it’s going wrong.
-
No, I don’t think so. Is that perhaps where it’s going wrong.
Possibly. I have no experience of cascading one instance of screen inside another. If I need two instances running they run as 'siblings'. When running a single detached instance, 'screen -r' reconnects to it. When running two (or more?) detached instances 'screen -r' lists the instances so you can select the one you wish to reconnect to.
For example:
martin@rpi:~ $ screen -r
There are several suitable screens on:
9333.pts-0.rpi (07/08/19 13:05:20) (Detached)
9325.pts-0.rpi (07/08/19 13:05:01) (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.
'screen -r 9325' resumes the first screen session that I started.
-
I keep getting disconnected by the fact that the iPad times out and drops the ssh tcp connection. So I need to automatically get the other end, the pi, to run a screen or in an auto login batch script so that it will just pick up where it left off. Is that feasible?
-
My suggestion is for you to stop all your current work and save everything. Now reboot the R-Pi. That will clear all the multiple screen sessions that have built up.
The "screen" utility can be built (and ported to) various OS' in many, many, ways. I am familiar with that available with RHEL, less so with the Debian version for the R-Pi.
Start your screen session with "screen -U". When you have been disconnected, possibly by some LAN/WLAN glitch, reconnect with a "screen -dr" incantation.
To completely terminate the current screen session, issue "<Ctrl-A>K". (Control-A followed by an upper-case K.)
To temporarily detach from your current screen session, issue "<Ctrl-A>d. (Control-A followed by a lower-case d.)
To re-attach to a detached screen session, it is as three lines above: "screen -dr".
If you would like to start a screen session which logs everything that occurs, "screen -L -U" would be the relevant incantation.
Finally "man 1 screen" should bring up the relevant manual page on your R-Pi.
-
Many many thanks for that advice, which will be investigated and acted upon.
At the moment I have a .bash_profile which may be doing the wrong thing. This runs screen (that’s the idea anyway) when the ssh connection is resumed. Until I read your advice it was screen -r weaver now changed to screen -dr weaver (with || error-handling).
I have had an epiphany but am unsure. There is a second shell, called ds64_shell (see vic0239’s original post) which gets you into AArch64 mode in the Debian Buster 64-bit o/s. When I run this, it could be that that is where things are going wrong. I wonder if ds64_shell runs certain at-login time style shell script(s) .bash_profile - can soon find out, with a bit of crude printf-style or similar debugging (or echo New_shell_started >>leth_radan.log)
If it turns out that that is happening then that could be the cause of double-screen, no? And do we think that screen is too thick to prevent running itself through its own self?
-
Have a play with tmux as an alternative to screen.
Been using it for yonks now and never had these bits of oddness that screen would suffer from.
(of course, only a suggestion - tmux may or may not be suitable for you)
-
The experiment using logging gave the expected result. Launching ds64_shell by hand gave the expected shell-within a shell result, so that should mean a screen within a screen unless it has the wit to do the right thing (®) in advance when there is already an existing screen session.
Thanks for the tip about tmux. Any care and feeding instructions needed?
-
It has not been mentioned yet, garbage from arrow keys, etc. is often indicative of an incorrect setting of the TERM environment variable. It is passed via an ssh command by default so this may help when connecting.
TERM=screen ssh myhost
-
It is perfectly possible to have a screen session within a screen session within a screen session within . . . (you get the idea)
The only problem with a chain of screen sessions is that it is impossible to give a directive to the Nth session, as the very first session will respond to the <Ctrl-A> and act upon the directive.
As for tmux, I only looked at it briefly, when RHEL8 was released and decided that I should just build the screen package for that OS. It is now in routine use by my colleagues and I. (Having been so used to using screen, since the days of RHEL5, to learn the intricacies of tmux was just too much effort. It was simpler to build the screen RPM package.)
-
If you want to run screen within screen then the second can use different escapes. Use the -e option, the default is equivalent to -e^Aa
-
I quite like tmux because it allows for "panes" within the terminal and each pane can be used for doing different things.
Very useful when I am working with remote data centers in my case, because I can log into a few devices remotely at once and run various pings etc when performing maintenance and such.
Not sure if you can run tmux on an iPad though.