I've created a .screenrc config file to setup some split screen stuff for what im working on, and i've bound ctrl+d to quit it, but it only quits the screen, and leaves the actual processes running.
Heres the bind keys part of my .screenrc file atm, is there a way i can tweek it so it kills processes too?
bindkey ^D quit
It needs to quit and kill multiple split screens btw so that may add to the complexity of it.
Ultimately i'd like to bind it to Ctrl+C or Ctrl+D, either way a quick way to exit this script as its a custom script loading this custom .screenrc file.
Thanks.
Unsure if you are aware of the screen ctrl a functions
ctrl a c to create a new screen
ctrl a a or [0-9] to run through connections
ctrl a d to detach
where you can then use
screen -r -d to re-attach
and I think you need
ctrl a \
this will attempt to quit the screen session and prompt if you wish to cancel it all
Related
I need script which works in the background, waiting for a key to be pressed. I have a script which works when terminal is on. When I try to use & - it's not working correctly. The script works in background but keypress doesn't do anything. When I try use nohup then I have error of read - bad descriptor.
Can someone help me?
When the terminal is on (and is selected, in case of a terminal emulator running on x server), the input (key strokes, etc.) is directed to the terminal; hence, your program works.
Now, consider an example: let's say that you created a script that runs on the background, and it is activated by pressing the letter "a". If pressing "a" triggered your script (with terminal closed), then the user would never be able to (for example) type the letter "a" in a word document or a web search without triggering the script!
Therefore, what you are looking for is a key bind, or a keyboard shortcut, which would bind a key (combination) such as ctl+j+k to launch the script you want.
In Linux, that can be done somewhat easily, see this for Ubuntu or this for Lubuntu.
Important: if your script needs to be root to work, then you generally will have to evoke it via gksu or gksudo, otherwise it will not run
Here I want to ask you to help to bring the console window top most with a shell command. Is it possible?
there was a script execution in my work environment, and will take about several minutes to complete, I will move to other work while running, it is better there are some tips to notify me when script completes run.
So I think bring the window top most is the most direct way.
Please tell me how to achieve this, I'm working on windows, new to MacOS.
Thanks,
Levi
I don't know how to bring the console window to the front, but if you're working in the terminal, you could do something like:
$ path/to/script ; tput bel
or
$ path/to/script ; say "script 1 is done"
Where path/to/script is whatever your usual method of loading the script is.
I recommend the first method, as it flashes the screen, makes a beeping noise, and causes the terminal icon to bounce up and down on my dock in OS X 10.10. The second might be better if you need to figure out which script is done from among a bunch of scripts. If you have coworkers who you don't want to disturb, you can change the preferences in terminal so that an alert only flashes the screen and doesn't also make a noise.
If you have access to the source code of the script, you can also add tput bel or say "command" to the last line of the script and you'll get the same behvaior.
In other terminals I would press Ctrl+z to suspend an application, often to then issue bg to send it into background.
In console2 Ctrl+z does nothing, probably because the key combination has a different meaning in Windows. But is there a way to achieve the same effect, save for 'process &'?
(I know I should use & and it works, but sometimes I would setup shell, start an editor, begin editing, then return to the console just to find that I forgot the & and I can't use the shell. It annoys me that I then have to either open a new shell and set it up again, or quit the editor, start it with & and set it up again).
In Console2, ctrl-c is bound by default to copy (text) you have to press ctrl-shift-c to cancel job.
You could also try to remove the hotkey that is conflicting with ctrl+z.
I was having trouble using ctrl+c to cancel the execution of a script. As soon as I removed that hotkey, ctrl+c had its default restored and I was able to cancel executions properly.
This annoying issue surely is a console2 bug. You may find something about at its issue tracker.
Anyway, what ctrl+z does is send a SIGSTOP signal to current process. So, you can still send that signal from another session/tab. (If it is less annoying than stop and start with &).
To do that, you can use the kill command.
kill -s SIGSTOP pid
(pid is the process PID number)
Hope it helps.
I want to view the output of a bash command in a vim split window :split. To this end I installed "Conque Shell" which displays bash in a split window upon :ConqueTermSplit bash. I can then run my shell command and watch the output in insert mode. However, to return to the other window I need to type <CTRL-W> <Up> in command mode, so I need to leave insert mode. Hence the display of the command output freezes and continues only if I return to this window and enter insert mode. So how can I leave "Conque Shell" without leaving insert mode.
Note that other ways of viewing the bash output in a second window might solve my problem as well. However it should update while I am working in the other window and allow me to signal e.g. <CTRL-C> to the application.
The ConqueTerm documentation says:
3.1.5 Keep updating terminal buffer *ConqueTerm_ReadUnfocused*
If set to 1 then your Conque buffers will continue to update after you've
switched to another buffer.
Note: Conque buffers may continue to update, but they will not scroll down as
new lines are added beyond the bottom of the visible buffer area. This is a
limitation of the Vim scripting language for which I haven't found a
workaround.
>
let g:ConqueTerm_ReadUnfocused = 1
AFAIK Vim has no support for asynchronous sessions, so this is more of a response to your request for potential alternative options.
The way that I currently get around this issue is by using tmux, which is described as:
a terminal multiplexer: it enables a number of terminals (or windows),
each running a separate program, to be created, accessed, and
controlled from a single screen.
So, basically, instead of splitting your screen in Vim you would split it using tmux, and then in one window run Vim and in the other run whatever other program you want which will update completely independently of Vim. And just like Vim you can switch between the windows (or panes as they are called in tmux lingo) using a couple of key strokes.
There is another terminal multiplexer available called GNU screen, which is also quite popular. And the reason I mention that is because I like to have options, and also there are two plugins for Vim that allow you to send output directly to an attached screen or tmux session. For GNU screen, slime.vim, and for tmux, tslime.vim.
Using VIM and ConqueTerm you can use CTRL + W and UP / Down to change windows in split mode.
Just click on ESC first to exit the insert mode.
It works well on my side.
I'm running MATLAB (command line version) from a shell script, and I'd like it to preserve shell behavior where if you press Ctrl-C it exits. But instead it wants to keep control of the terminal and I (or my poor users after me) have to type quit(1) to make it quit and tell the shell it failed.
You can't intercept Ctrl-C with a try/catch block... any other ideas? Anything I could do from the shell side to intercept the keystrokes before they get to MATLAB?
onCleanup seems like an option, but then I'd have to make the whole script thing into a function (it's already a dynamically generated try/catch block thing in a Makefile). But if that's the only thing that will work, then I'll do it...
Use onCleanup:
I wanted to do the same thing but after I read this thread I used onCleanup successfully. My problem was I had a server in Matlab that when pressing CTRL+C would keep listening on the port it was started on -> second run I would get a bind error.
You can try:
stty quit ^C
but I have no matlab to test it.