Is it possible to manually abort the currently running bash command? So, for example, I'm using 'find' but it's taking ages... how do I manually stop it?
Some things won't respond to Ctrl+C; in that case, you can also do Ctrl+Z which stops the process and then kill %1 - or even fg to go back to it. Read the section in man bash entitled "JOB CONTROL" for more information. It's very helpful. (If you're not familiar with man or the man pager, you can search using /. man bash then inside it /JOB CONTROLEnter will start searching, n will find the next match which is the right section.)
Ok, so this is the order:
1st try: Ctrl+c
2nd try: Ctrl+z
3rd: login to another console, find the process of the command within your first console that is not responding to both previously mentioned abort/sleep keystrokes with: ps aux
Then kill the process with: kill -9 <PROCESSID>
Of course there may be smarter parameters to the ps command or the possibility to grep , but this would complicate the explanation.
Press CtrlC to send SIGINT to the command to attempt to interrupt it.
Related
I have this command in my shell script that runs forever- it wouldn't finish unless I do ctrl-c. I have been trying to look up how to send ctrl-c signal to script and all the answers have been some sort of kill $! or kill$$ or such. My problem is that the command never finishes, so it never goes on to the next command like my "kill" commands or anything else. I have to manually hit the ctrl-C in my terminal for it to even execute kill $!. I'm sure there is a way to work around this but I am not sure what. Thanks in advance!
There are several approaches to this problem. The simplest (but not most robust) is (perhaps) to simply run your long running command in the background:
#!/bin/sh
long-running-command & # run in the background
sleep 5 # sleep for a bit
kill %1 # send SIGTERM to the command if it's still running
I am trying to learn about process substitution and when I execute this:
$ tee >(wc -l) <<< $'aaa\nbbb'
aaa
bbb
$ 2
bash prints the number after the next prompt and waits for me to press enter.
I am using bash 4.4.12, experiencing the same issue with bash 4.3.48. There is no issue in bash 4.3.30 and the command correctly outputs:
$ tee >(wc -l) <<< $'aaa\nbbb'
aaa
bbb
2
What could be the possible issue?
It's a quirk / design flaw with process substitution; bash only waits for the main command to terminate. It doesn't wait for substituted processes to end. It creates a race condition when tee ends: does wc finish before bash prints its next prompt? Sometimes it does, sometimes it doesn't.
See this Unix.SE answer by Stéphane Chazelas for a detailed explanation and possible workaround.
When you use process substitution, the process you're substituting runs in the background, and the shell doesn't wait for it to finish before displaying the prompt.
Sometimes it will display its output before the shell displays the next prompt, sometimes it will be a little slower. It has nothing to do with the version of bash, it's just purely by chance which process is faster.
The shell is waiting for you to press enter because it's already displayed the prompt and it's waiting for you to type another command. The shell doesn't know anything about the 2 that was displayed while you were at the command prompt -- that's output, not part of your input.
This is generally not an issue because you don't usually use process substitution with programs that display output to the user interactively.
Let me start of by saying i just started learning linux.
I have a command that keeps processing/loading until i press CTRL+C to cancel/stop the command and remain in session.
What i want is to send that command, wait x amount of seconds and then close it programmatically in a single command (cause i can't enter new commands when its loading). Sorry if it sounds stupid, but that would solve my problem.
Would really appreciate if someone could've helped me out here, couldn't find anything on google that was working (mostly exiting the session while the command remains loading).
Use sleep command for terminate the process.
example:
echo helloword & sleep 1 --> time indicates in seconds.After executing the echo command it will wait for one second and then it terminate the echo process
use nohup. example:
nohup ./foobar.sh & < /dev/null > ./log 2>&1
exit
In foobar.sh you can have the following content
command you wish to execute
sleep <no of seconds>
or you can use "screen", you need to install "screen" in you host, then
> screen {your-cmd}
and press ctrl+A followed ctrl+D detach current (but your cmd still running) session .
I would like to configure my bash in a way so that I react on the event that the user enters a command. The moment they press Enter I would like my bash to run a script I installed first (analog to any PROMPT_COMMAND which is run each time a prompt is given out). This script should be able to
see what was entered,
maybe change it,
maybe even make the shell ignore it (i. e. make it not execute the line),
decide on whether the text shall be inserted in the history or not,
and maybe similar things.
I have not found a proper way to do this. My current implementations are all flawed and use things like debug traps to intervene before executing a command or (HISTTIMEFORMAT='%s '; history 1) to ask the history after the command execution is complete about things when the command was started etc (but that is only hindsight which is not really what I want).
I'd expect something like a COMMAND_INTERCEPTION variable which would work similar to PROMPT_COMMAND but I'm not able to find anything like it.
I also considered to use command line completion to achieve my goal but wasn't able to find anything about reacting on sending a finished command in this, but maybe I just didn't find it.
Any help appreciated :)
You can use the DEBUG trap and the extdebug feature, and peek into BASH_COMMAND from the trap handler to see the running command. (Though as noted in comments, the debug trap is sprung on every simple command, not every command line. Also subshells elude it.)
The debug handler can prevent the command from running, but can't change it directly. Though of course you could run any command inside the debugger, possibly using BASH_COMMAND and eval to build it and then tell the shell to ignore the original command.
This would prevent running anything starting with ls:
$ preventls() { case "$BASH_COMMAND" in ls*) echo "no!"; return 1 ;; esac; }
$ shopt -s extdebug
$ trap preventls DEBUG
$ ls -l
no!
Use trap - DEBUG to remove the trap. Tested on Bash 4.3.30.
Let me explain better. What is gonna happen if I run a command in Linux and before it's done and you could enter another command I close the terminal. Would it still do the command or not?
Generally, you must expect that closing your terminal will hangup your command. But fear not! Linux has a solution for that too!
To ensure that your command completes, use the nohup argument first. Simply place it before whatever you are trying to do:
nohup ./some_program
nohup ./do_a_thing -frx -file input_file.txt
nohup grep "something" giant_list_of_files/* > temp_file.txt
The nohup command stands for "no hangup" and it will ensure that the command you execute continues to run, even if you close your terminal.
It depends on the process and your environment (job control shell options, VNC, etc). But typically, no. The process will get a "hangup" signal (message) from the operating system, and upon receiving that, will quit.
The nohup command, for example, arranges for processes to ignore the hangup signal from the OS. There are many ways to achieve the same result.
I would say it will abort att the status you are in just before the session close.
If you want to be sure to complete the job, you will need to use the nohup command.
http://en.wikipedia.org/wiki/Nohup
Read about nohups and daemons (-d)...
A good link is [link]What's the difference between nohup and a daemon?
Worth look at screen command, Screen command offers the ability to detach a long running process (or program, or shell-script) from a session and then attach it back at a later time.