I'm using Mac OS, communicating with a micropython board over serial. Specifically, it's an ESP32. In terminal, I enter this.
screen /dev/cu.usbserial-02522F59 115200
This works well, I'm communicating with the board in an interactive repl.
Now, I want to google something, so open Safari. After I go back to Terminal, I can't type. The ctrl-a commands work, but that's it.
Here's what I've tried.
ctrl-a (^a from now on) w, listing the windows that are open. There's only the one window. Next, ^a 0, switch to window 0, no success.
combed the man page, found nothing that fixed my problem.
googled the problem. I found all sorts of things about people's displays not working, but nothing about the screen command.
The only thing that works is ^a ^\ or ^a k, killing the window or the whole process, then starting over.
I'm new to the screen command. Any help is appreciated.
Thank you in advance.
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.
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.
I experience a lot of blinks while typing with YCM (YouCompleteMe) in Windows. (the file is fairly large, I use only identifier based completion in YCM; But in Mac and Linux with the same file, it doesn't blink at all and feels very smooth).
See attached screenshot for clues.
I guess this might not be YCM's problem, but anyone has any clues why this happens?
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.
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!