How do I clear the console screen in an LLDB session terminal? I know in GDB this is done with shell clear
(Ctrl+L does not work for my case since I am running my LLDB session in VSCode debug console)
In the gdb case, shell clear is spawning a sub shell and calling that shell's clear command. Because the shell is sharing the same terminal with gdb, this acts to clear the terminal.
In the case of VSCode, lldb isn't directly connected to a terminal, it's just feeding text to VSCode through a socket. So it has no influence over the window VSCode chooses to display the text in. The VSCode-lldb interface would have to have a "clear your console" primitive for it to work in cases like this. That does not exist on the lldb side. I don't know whether it exists on the VSCode side.
Related
I periodically get thrown into the emacs editor in vscode, when I issue git commands.
For example, I'd like to edit the commit message for git, but the standard emacs key sequence ctrl-X ctrl-C is not accepted in the terminal window. This makes it difficult to exit emacs in the standard way.
I assume it's not being sent because MacOS or VSCode is intercepting the key combination.
I also assume that if MacOS was intercepting a two-keystroke combination, I would have noticed when running emacs on the MacOS terminal program (Unix shell prompt)
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.
If i launch a executable/another app from a bash script, this executable/app starts up normally, but with it's application window not in focus.
If you launch the script from a window for example, the bash script calls upon the other executable/app, but you can't see the app's interface because it gets launched below all windows.
For Linux there exist some window managers that can do this, like these tips here:
Is there something for OSX as well?
I realize i can set the active window via AppleScript (osascript via bash), but i wanted to do this without AS.
("tell application \"newapp\" to
activate")
My appswitch tool does exactly this.
My specific problem is the following: I am using Mac OS X with the Visor app for terminal. This lets me do cool pop-in/out stuff with terminal for quick access. The problem is, I lose the ability to move the window around and re-size it, something that becomes important when I start opening up multiple buffers in emacs and want to view some at the same time in a window larger than 80 wide.
Does anyone know how to duplicate a shell window/instance, so that a new window appears with the same history, current working dir, aliases, etc...? Even more specifically, can this be done in Mac OS X such that the new window is in a different "style", (basic, pro, sands, etc..).
I'm not familiar with Visor, but simply using a terminal emulator such as screen might give you what you need. From a terminal, invoke 'screen'. That will give you a shell prompt. From another terminal, invoke 'screen -x'. Now each terminal will be attached to the same shell, with the same history, etc. See screen(1) for details.
I'd like to be able to launch a process from a GUI application (right now I'm thinking specifically of letting an eclipse user -- possibly via a plugin -- click a button to launch a build using my organization's build system).
I don't want this process to stop when I stop the parent application, and I want to be able to "switch into it" later, as though I launched it from a command line.
I've seen GNU screen described as good for most of what I'm asking for, but I'm not sure about the "launch the process from another application" part.
Can this be done if the GUI application was itself launched from within screen? Can this be done if it wasn't? I'd be very interested in seeing how!
Update:
Prepending "screen" to a command line looks like a good way to start a process in screen from a shell, but I'm trying to find a way to do this without being taken straight into that session. I want to "send" the command to a screen session, where it will be started in a new window in that session.
simply prepend the 'screen' command to your normal commandline.
E.g. if you normally execute "./make_build.sh opt1 opt" then your screenified commandline would be "screen ./make_build.sh opt1 opt2"
Its that easy! :-)
You can send screen messages to a running screen session with the -X flag.
See How to start a new process in a new window in an existing GNU screen session, from outside the session or the screen man pages.
If you can suspend the process (via Cont-Z) you can then run
screen -dr -X screen $(fg)
It will attach that process to a new window in the screen. Its not ideal, but it will work.