I have bound a key on my screen, via screen command line and not the screenrc. Unfortunately by error I bound the key was "E", what I wanted was Ctrl-A E.
Then I was not able to type in my terminal the char "E", which is the expected behavior, screen is running my command...
What is weird, is that when I try to unbind the key by screen's command line, I am not able to insert "E", because screen is still executing the bound command.
So then, I am blocked here!? I am not able to type anymore "E", the only solution is to kill my screen session and start it again, something that I want to avoid, I have a lot of running stuffs on this session...
I have also tried to type in another editor: bindkey "E" and copy/paste it to screen's cli, it pastes every chars but "E"?
It seems to be a minor bug in screen, it should not execute bound commands when user is typing a screen command...
Thanks
I found a hint, I really want to share it with gnu-screen's users.
To unbind the key, I have get the octal value of my char "E", which is 105, and then I typed:
:bindkey "\105"
in the screen's command line.
This resolved my issue but I am still thinking that it is a bug in gnu-screen.
If you have another way to do it please share it. I am still interested.
Regards,
Related
When working on Hive queries through Beeline command line interface, I can't get the upper arrow (and other arrows, mouse wheel up/down, page up/down) to work. It simply shows
0: jdbc:hive2://remoteserver:10000> ^[[A^[[B^[[D^[[C^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[A^[[A^[[A^[[A^[[A
If I exit and back to my bash shell CLI, the upper arrow (and other key press functions) works fine.
It becomes annoying as I need to retype historic queries all the time. Is there a way to solve this issue?
Solved: for those in similar situations, here is my work-around. The server seems to have readline library installed, but somehow my account was not set up to use readline properly. Thus I installed https://github.com/hanslub42/rlwrap/blob/master/INSTALL and use "rlwrap -a beeline" instead.
I'm trying to use the WSL console in Windows 10 (version 1909) for some development work, but I find that often running processes will simply appear to have hung, but when I send a keystroke to the terminal it will update back to the bash terminal (as if had completed all along but hadn't updated).
I am running the latest version of the debian package from the store.
Is there anyway to make this problem go away or am I wasting my time trying to use the default terminal?
Just a hunch, but I am guessing you are ending up in select mode. If you click anywhere in the terminal the title of the window will change to be prefixed with "select" and the terminal output will freeze so that you can select text without it changing while you try to highlight it. Pressing any key will cause you to exit select mode.
If this bothers you you can turn it off by right clicking on the title bar, clicking properties, and disabling quick-edit mode. Alternately, might I recommend the new Windows terminal, which handles selection and the clipboard in a more intuitive way.
I'm configuring GNU screen in a cygwin environment. Re-configuring actually--it always just worked before, and when I upgraded to cygwin-64 the same config files give me unexpected behavior.
What happens is that whenever I do something in the terminal that overflows a full screen the terminal does not scroll. Instead, each new line "overwrites" the last one on the bottom row of the window. Even when the process is through, if I CTRL+l, there's a bunch of garbage left on the last three lines of the terminal. Also, when I use a program that takes up the entire screen, such as vim or irssi, the "caption" line disappears.
I suspect that there's some discrepancy between my xterm settings and screen's 'term' setting, but I'm a little at sea here and, as I said, all the same configuration files worked fine (and do work fine on other machines--both cygwin and native linux). Can anyone recommend a way to get my beloved screen to behave again?
Here's my .screenrc:
shell /bin/bash
screen -t bash 0
select 0
escape ^Zz # Instead of Control-a, make the escape/command character be Control-z
autodetach on # Autodetach session on hangup instead of terminating screen completely
startup_message off # Turn off the splash screen
defscrollback 30000 # Use a 30000-line scrollback buffer
nethack on
# Misc h4x to make scrollback work
terminfo * te#:ti#
termcapinfo xterm|xterms|xs|rxvt ti=\E7\E[?47l
# Bells are annoying
bell_msg ''
vbell off
caption always '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'
You're running screen under xterm (something I do all the time myself). The screen process "knows" how big the terminal is, but that information can be out of sync with reality. I find this happens a lot when I run screen -dr from a different window.
Resizing the xterm windows causes it to send a SIGWINCH signal to the process running under it, which typically causes that process to re-query the tty settings.
Click the maximize button twice. If you're already maximized, that will restore it to a normal window and then re-maximize it; if it's not already maximized, it will do the opposite. In either case, it should cause screen to recompute the window size.
I encountered the same problem today. Thank everyone for the heads-up. The final solution I found out is that to set the mintty term type to: vt220. There must be something not right about the "xterm". After that, everything is good.
I'm answering my own question here because, while #Keith Thompson's answer does resolve the symptom of the problem, it didn't keep the symptom from occurring. He did set me on the right path, which was to install the xterm package in cygwin-64. That appears to have resolved the issue.
I downgraded screen version to Screen version 4.02.01 (GNU) 28-Apr-14 and it worked.
I would've thought this would be an easy thing, but when I use the rails console, if I query a variable that has multi-page output, I can continue scrolling until the console yields (END) but then I can't get out of that state without CTRL+Z, which requires me to restart said rails console to continue. I'd like to just exit that output, but CTRL+C, CTRL+D, ESC, and every other combo I can think of simply do nothing. I'm certain there is a way to do it, can someone put me straight?
Thanks
You're in a pager. Press "Q", for "Quit".
Sometimes when I am using less within a screen tab, the arrow keys display ^[OA, ^[OB, ^[OC, and ^[OD instead of doing what I want them to do. Is there something I can do to fix this and gain control of less again?
enter !reset at the less prompt
I have found that reset from within screen does not solve the problem sometimes, as it's the outer client/shell whose state is actually confused and screen captures the control characters from reset and prevents them from reaching the outer client. In this situation, I have to detach my session (Ctrl+a, d), run reset, then attach to the session again (screen -r).
If it happens from time to time, it seems, that some application (e.g. cat or less a binary file) shatters your console by sending it control characters. You need to run reset command from command line to recover.
Otherwise you have to trick your terminal application. I suggest you to use CryptoTerm which allows you to define custom key mappings.
Another thing to check is your TERM variable. In my case I ssh into a Linux box and run less inside screen - the TERM variable was set to 'screen' - which breaks arrow keys. It works perfectly if I run less this way:
TERM=xterm less <file>