everyone!
I installed ubuntu on vmware for working laravel framework.
I have problem with terminal.
when I move terminal window using mouse, running command is canceled.
Please see this...
hkg328#hkg328-virtual-machine:~$ ^C
hkg328#hkg328-virtual-machine:~$ ^C
hkg328#hkg328-virtual-machine:~$ ^C
hkg328#hkg328-virtual-machine:~$ ^C
whenever I move terminal window using mouse, following line appears in terminal.
hkg328#hkg328-virtual-machine:~$ ^C
What is the reason?
What should I do for solving this problem?
(When I move terminal using shift key+mouse drag It is ok.
But I don't want to use shift key.)
Thank you.
The likely problem is that your terminal has the xterm mouse-protocol enabled (usually from running some text-editor). Occasionally that does not clean up after itself (a problem with vim's plugins), and you'll even see this enabled on the shell command-line.
When you click in the text-area without shifting, that sends escape characters (and control characters) when xterm mouse-protocol is enabled. For xterm, at least, clicking/dragging the window border (including title area) shouldn't pass those escape/control characters to the application.
The use of the shift-key is built into the mouse protocol; if it's enabled you'll get that behavior -- always.
Related
The terminal begins to behave a little bit strangely after an SSH session inside has been terminated (due to sleeping the computer or killing it via <Enter>+~+.).
It causes a beep to be emitted whenever focus enters and leaves the particular terminal. Also when in my zsh shell, a blank new line appears to be fed into the terminal.
I've tested this in:
tmux in alacritty
raw alacritty
iTerm2
This is not a hugely annoying behavior, although the bell is definitely annoying for sure.
Today I was able to finally find a way to reproduce the behavior. Clearly this is somehow related to a terminal mode that SSH puts the terminal into and which it fails to clean up when it dies. But it is also related to the focus reporting.
I have tried stty sane but it does not work. Not even starting and quitting vim works. That usually is able to reset various other terminal state weirdnesses, such as being stuck in mouse mode where clicking the mouse on the terminal (and especially scrolling your mouse) produces lots of bells.
Inspired by the answer https://superuser.com/a/1017817/98199, I found that issuing the command echo '\x1b[?1004l' does effectively turn off the focus reporting, and restores normal behavior.
Since vim definitely is capable of recognizing focus events I do not know why starting and stopping vim does not do the trick for this. I suppose I will make this command into an alias and just run it when I need to.
I want to change some tmux styling when the terminal loses focus/becomes inactive (i.e. when I've clicked on an open Google Chrome window). I know I could check with the window manager to see which application window is focused, but this doesn't work across window managers.
Do terminal emulators themselves expose this information at all?
I tried running showkey -a to see if any escape sequence was sent when focus was lost, and it doesn't look like it.
I think some terminals implement this, but not all, based on this comment on the issue tracker for the vim-tmux-focus-events plugin:
About the question "I was expecting the event to fire when changing focus between different windows in my window manager": yea, I see how that would be very useful. I think this might be dependent on the terminal application you're using. I just tested this on OSX and here's some quick results:
it's working for iTerm when tmux is running inside the window
not working for iTerm running plain bash + vim inside (no tmux)
not working for Terminal.app (with or without tmux)
[...]
So, if I'm not wrong, it's up to terminal applications to implement "focus gained", "focus lost" functionality.
I have a vague memory (though I don't remember for sure) that focus gain/loss might have worked for me when using that plugin and gnome-terminal, so it might be worth a try.
Is there a way to scroll up the terminal right till your previous command, no more no less?
Ubuntu or mac.
The goal is to quickly find the beginning of the previous command output without spending time on scrolling and searching for it.
If you are running a gnome-terminal (default GUI terminal on ubuntu) you can hit shift+ctrl+f, type your search terms, and hit enter. Still graphical, but no mouse required.
Or
Finding text in scrollback is a weakness of most terminal emulators; the only ones I know of that provide it are OS X Terminal and Terminator. That said, you could run GNU screen in any terminal and search its scrollback buffer in copy mode.
I'm trying to debug why tmux processes still think they're attached when I close the terminal they live inside of, and I think I've discovered part of the problem; when I close a terminal window (CMD-W or clicking the little red button in the top left) it doesn't send SIGHUP! In fact, it only sends SIGEXIT. I discovered this using the script from this SO question. One of the posters gave a very different result from his OSX machine, however my terminal does not seem to want to play nicely.
Does anyone know how to make the terminal in OSX (I'm running 10.7.2) send the proper signals when exiting? Thanks!
The post summarizes problems in using Screen in Mac's terminal when you have the following in your .zshrc
if [[ $STY = '' ]] then screen -xR; fi
Solution #1 is not working but Solution #2 works: Clipboard programs: pbcopy, pbpaste and xsel do not work at all
Bug in Vim when used in Mac: Unable to have no scattered windows in Screen by .Xresources.
Solved: Ctrl A stops working in terminal. This suggests me that Screen's keyboard bindings need to be changed slightly.
Solved: The scrolling with touchpad does not work. By editing your .screenrc the scrollback works normally (including touchpad)
Solved: Unable to have Dvorak keybindings for Screen for moving in Scrollback mod.
How can you use pbcopy/pbpaste/xsel inside Screen?
In screenrc:
# Make xterm scrolling work properly with screen.
termcapinfo xterm-256color|xterm-color|xterm|xterms|xs|rxvt ti#:te#
Works for Terminal.app too.
I usually solve the ctrl-a problem by setting my escape character to ctrl-z (which you generally don't need to use as often when you're running screen, since instead of backgrounding a process, you can just start up a new screen). In my .screenrc:
escape ^Zz
Scrolling using the touchpad just isn't going to work; screen is acting as a terminal emulator inside a terminal emulator, and it's just not possible for screen to switch the scrollback buffer in Terminal.app whenever you switch between screens. You're going to have to use screen's scrollback features. See this article for some tips on using screen's scrollback features.
The default OS X Terminal app is weak. Get iTerm instead:
iTerm
If I'm not mistaken, iTerm solves all of these out of the box (my install is a couple years old, so I can't test that theory now).
Problem #3 might be solvable if you enable the alternate screen buffer. Use altscreen on in .screenrc
Solution #1 which does not work
To be able to copy/paste in OSX put the following to your .screenrc
bind b eval "writebuf" "exec sh -c 'pbcopy < /tmp/screen-exchange'"
> Th[e] line - - sends that file to pbcopy - -.
The command is bound to C-a b (in my case, C-z b).
Solution #2 which works but is rather slow to type
Use Scrollback mode i.e. copy mode by
Coping
C-A [
Pasting
C-A ]
The solution is great, since it is the same in all terminal apps. It is similar to the clipboard as you use with your mouse.
Q5: Impossible: The scrolling with
touchpad does not work.
You can use ^A Esc to scroll up the screen. You cannot use Touchpad in Screen.
This solves the scrollback issue, although it is somewhat broken in that it isn't aware of screen's buffers.
env TERM=vt100 screen