Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: SCREEN and arrow keys’ Esc sequences not recognised, shows visible garbage  (Read 998 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7752
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick

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.
Logged

MartinGoose

  • Member
  • **
  • Posts: 91

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.

Quote
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.

Quote
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.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7752
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick

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.
Logged

MartinGoose

  • Member
  • **
  • Posts: 91

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?
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7752
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick

No, I don’t think so. Is that perhaps where it’s going wrong.
Logged

MartinGoose

  • Member
  • **
  • Posts: 91

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:
Code: [Select]
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.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7752
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick

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?
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27453
  • Over the Rainbow Bridge
    • The ELRepo Project

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.
« Last Edit: August 08, 2019, 12:03:16 AM by burakkucat »
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7752
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick

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?
Logged

displaced

  • Reg Member
  • ***
  • Posts: 172

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)
Logged
Vodafone Landline+FTTC: Huawei DSLAM, HG612 modem, pfSense router, Ubiquiti access points. GigE home LAN with Netgear ProSafe switches. Mac, FreeBSD and Win10.

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7752
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick

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?
Logged

petef

  • Member
  • **
  • Posts: 92

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
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27453
  • Over the Rainbow Bridge
    • The ELRepo Project

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.)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

petef

  • Member
  • **
  • Posts: 92

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
Logged

dee.jay

  • Reg Member
  • ***
  • Posts: 345

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.
Logged
Sky FTTC 69/17 @ 3dB SNR - HG612
AAISP FTTC 67/16 @ 3dB SNR - HG612
Routed by pfSense on VMware ESX 6.0
~600M Huawei cabinet