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.
Related
Using XTERM control sequences (specifically CSI ?1000h), I can get notified on stdin any time the user clicks on the terminal window. Unfortunately this also means I get notified if the scroll wheel is spun, instead of normal terminal scrolling taking place. Is there any way to, preferably easily and simply, just get notified about clicks and nothing else?
Alternatively, is there a way to send an escape sequence that the terminal emulator will interpret as "oh, you want me to scroll normally"? I'd be (reluctantly) okay with having to parse all the mouse commands, and then if I notice a scroll-up signal (button 96 or 64 depending on mode), echo it back saying "here, terminal, you handle this one". In theory these should be the scroll-forw and scroll-back actions, but I haven't found a way to use these directly.
If it makes any difference, I'm using xfce4-terminal, but am willing to try other terminal emulators if it would help with debugging this.
The X10 protocol sends only clicks (no wheel mouse). That's documented. But that's for xterm.
VTE (checking just now with XFCE Terminal) differs from xterm by sending wheel-mouse events. VTE has no documentation worth mentioning, aside from its source-code (ymmv).
The scroll-forw and scroll-back actions are xterm features, for which there are no counterparts in VTE.
As the title suggests, my touchpad won't move my mouse. I am therefore unable to select outputs of my commands, but I am able to take screenshots of windows. (Luckily I am used to using keyboard shortcuts)
I have no clue what caused this. I have recently updated my kernel from linux52 to linux53 and linux54. Falling back to either of those versions from linux54 hasn't helped. I have also recently been playing around with a Wacom tablet, using xsetwacom, but I believe my mouse has worked after this.
I know it's not a hardware issue, as libinput debug-events correctly detects my finger running over the trackpad:
The output of 40-libinput.conf in /usr/share/X11/xorg.conf.d/40-libinput.conf is the following. I can't see any error there.
I tried blacklisting the i2c_hid, as suggested in the following question, but to no avail. It fixed an error claiming there was a duplicate mouse, which it decided to ignore. I thought this would help.
What is surprising is that I can click. I can't scroll or move the mouse, though. My trackpad lists the following settings. To my surprise, there is no Accel Speed there, and I can't manually set it with xinput --set-prop 14 'libinput Accel Speed' 1.0, as I need to specify the type and format. I don't know what these are supposed to be, and I don't know if the acceleration is the issue. I read that having a negative value would cause the mouse to never move, though.
Do you have any suggestions as to what to do? What does libinput do with the events after receiving them?
EDIT: Removing the blacklist i2c_hid from the modprobe returns the following Xorg log:
Making a copy of /usr/share/X11/xorg.conf.d/70-synaptics.conf into my /etc/X11/xorg.conf.d/ folder, and commenting out the Option "Ignore" "on" line fixed it.
Had to sudo pkill X after changing it, of course. A reboot would also do the trick.
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.
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>