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!
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.
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.
Quite often but not always I'd receive some strange keystrokes in my terminal(OS X El Capitan). It looks like a sequence of:
^[[O^[[I
^[[O^[[I^[[O^[[I^[[O^[[I^[[O^[[I^[[O^[[I^C
this is so annoying especially when I have vim open it seems to bring up identifier search and I have to hit Enter to continue each time. I can verify this happens in iterm2 as well.
Did this ever happen to anyone else?
Those are an artifact of the changes in El Capitan to support xterm-style mouse protocol. The odd characters can tell a program when the mouse has moved in/out of the window (or clicked to gain/lose focus).
Some application you have run turns on this feature without handling it properly (or stopping it when the application ends).
Further reading:
FocusIn/FocusOut (XTerm Control Sequences)
Mouse Tracking (XTerm Control Sequences)
When i re-attach to an existing/running window, the screen doesn't seem to be responding.
I can key in the input but no output displayed on the screen. When i do screen -ls, the screen and the socket is still there.
Anyone has any idea what could have probably happened prior to this? I could only restore the functionality by rebooting the server. Not sure if something has been broken between the screen and shell due to bad characters.
I've seen this happen -- typically when I foolishly suspended output to my terminal (like when I fat finger and hit CTRL-S or some other nonsense). We leave quite a few processes running in screen, so it's always a panic moment when we get a hung screen session.
The solution is to identify the sshd session associated with screen, and kill it. This will free the screen and allow you to re-attach from another ssh session. (note: be careful to NOT kill the main sshd or you may not be able to login remotely).
I find pstree -ac invaluable in these situations.
If the command that you run for the screen will terminate soon, the screen will show as blank and not show the output.
But if you run command like top python3 -m http.server nano * that will not terminate soon, the screen will show.
EDIT
To solve this problem, you can run exec echo "hello world" after create screen.