How to stop a bash while loop running in the background?
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
19
down vote
favorite
I started a while loop as follows:
while true; do command; sleep 180; done &
Notice the &
.
I thought when I killed the terminal, this while loop would stop. But it is still going. It has been hours since I killed the terminal session.
How do I stop this while loop?
command-line bash process job-control
add a comment |Â
up vote
19
down vote
favorite
I started a while loop as follows:
while true; do command; sleep 180; done &
Notice the &
.
I thought when I killed the terminal, this while loop would stop. But it is still going. It has been hours since I killed the terminal session.
How do I stop this while loop?
command-line bash process job-control
add a comment |Â
up vote
19
down vote
favorite
up vote
19
down vote
favorite
I started a while loop as follows:
while true; do command; sleep 180; done &
Notice the &
.
I thought when I killed the terminal, this while loop would stop. But it is still going. It has been hours since I killed the terminal session.
How do I stop this while loop?
command-line bash process job-control
I started a while loop as follows:
while true; do command; sleep 180; done &
Notice the &
.
I thought when I killed the terminal, this while loop would stop. But it is still going. It has been hours since I killed the terminal session.
How do I stop this while loop?
command-line bash process job-control
edited May 9 at 22:31
![](https://i.stack.imgur.com/vXxhs.jpg?s=32&g=1)
![](https://i.stack.imgur.com/vXxhs.jpg?s=32&g=1)
Monty Harder
30316
30316
asked May 9 at 5:57
Saqib Ali
2981312
2981312
add a comment |Â
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
33
down vote
accepted
I started
while true; do yad; sleep 60; done &
and closed the terminal to test it, now I got the same problem.
If you already closed the terminal you've started the loop in
Let's get an overview of running processes with ps fjx
, the last lines on my machine read
2226 11606 11606 19337 ? -1 S 1000 0:00 _ /bin/bash
11606 22485 11606 19337 ? -1 S 1000 0:00 | _ sleep 10
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
1 2215 2215 2215 ? -1 Ss 1000 0:00 /lib/systemd/systemd --user
2215 2216 2215 2215 ? -1 S 1000 0:00 _ (sd-pam)
You can see yad
as a subprocess of /bin/bash
, if I close yad
it changes to sleep 60
in the output of ps
. If the tree view is too confusing you can also search the output as follows1:
ps fjx | grep "[y]ad" # or respectively
ps fjx | grep "[s]leep 60"
The output lines begin with two numbers, the first being the PPID, the process ID of the parent process and the second being the PID, the ID of the process itself. It's because of that 9411
appears in both rows here:
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
That's the bash
subshell we want to kill and we just found out its PID, so now everything that remains is a simple
kill 9411 # replace 9411 with the PID you found out!
and the annoying subshell is gone for good.
1: The notation as grep "[y]ad"
instead of simply grep yad
prevents the grep
process itself from showing up in the results list.
If you have the terminal still open
bash
provides the variable $!
, which âÂÂexpands to the process ID of the job most recently placed into the backgroundâÂÂ, so the following just kills the latest process in the background:
kill $!
If it's not the latest process, just can get a list of running jobs with the jobs
builtin, example output:
[1]- Running while true; do
yad; sleep 60;
done &
[2]+ Stopped sleep 10
There are two jobs in the job list, to kill one of them you can access it with the job number or the shortcuts %
, %+
(âÂÂcurrent jobâÂÂ) and %-
(âÂÂprevious jobâÂÂ), e.g. to kill the loop running in the background you could do
kill %1 # or
kill %-
and to kill the suspended sleep 10
job:
kill %2 # or
kill %+ # or
kill %
add a comment |Â
up vote
5
down vote
I need to note that when you close the terminal where you entered that command, the sub-command should've died along with it. Trying to reproduce this showed this behavior.
Now, assuming that you indeed are in a situation where this didn't happen, one way to go about killing the program you left running in the background, which was caused by the &
at the end of the command, is as follows:
- Open a new shell and run
echo $$
to note your current PID (process ID), so that you don't kill your own session. - Identify the PID of the program you think is still running; you can do this using the
ps -ef | grep $SHELL
command to find which programs are running a shell. - Note the 2nd column from the left and note the numeric value that differs from your
echo $$
result above; this is the PID you want to kill. - Run the
kill -SIGTERM <pid>
command, where<pid>
is the numeric value you identified in step #3 - Confirm the program is no longer running by repeating step #2
You could also restart your session or your computer, but the above will allow you to avoid that.
1
You could also usetop
to kill the process by pressingk
, then entering the PID, then pressing enter twice.
â luk3yx
May 9 at 6:19
add a comment |Â
up vote
-1
down vote
The &
will make the terminal create a new process and get your code to run inside it. So your code becomes independent from the terminal process. Even if you close the terminal the newly process in which your code is running won't stop. So either remove &
or do ps -aux
, locate your process and kill it kill (process id)
.
add a comment |Â
up vote
-3
down vote
Usually bg for background fg for foreground. If you use & symbol use fg it will show the current running program. Press Ctrl+C to kill.
3
Usingbg
/fg
won't work once terminal is detached frombash
. Would be unable to reattach usingreptyr
becausebash
has child processes (sleep
).
â xiota
May 9 at 7:04
He closed terminal because he will kill that process. So next time he will use fg to close the program. Simple
â Curious
May 9 at 9:28
@Curious that's next time. But OP is asking about this time.
â RonJohn
May 9 at 22:35
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
33
down vote
accepted
I started
while true; do yad; sleep 60; done &
and closed the terminal to test it, now I got the same problem.
If you already closed the terminal you've started the loop in
Let's get an overview of running processes with ps fjx
, the last lines on my machine read
2226 11606 11606 19337 ? -1 S 1000 0:00 _ /bin/bash
11606 22485 11606 19337 ? -1 S 1000 0:00 | _ sleep 10
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
1 2215 2215 2215 ? -1 Ss 1000 0:00 /lib/systemd/systemd --user
2215 2216 2215 2215 ? -1 S 1000 0:00 _ (sd-pam)
You can see yad
as a subprocess of /bin/bash
, if I close yad
it changes to sleep 60
in the output of ps
. If the tree view is too confusing you can also search the output as follows1:
ps fjx | grep "[y]ad" # or respectively
ps fjx | grep "[s]leep 60"
The output lines begin with two numbers, the first being the PPID, the process ID of the parent process and the second being the PID, the ID of the process itself. It's because of that 9411
appears in both rows here:
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
That's the bash
subshell we want to kill and we just found out its PID, so now everything that remains is a simple
kill 9411 # replace 9411 with the PID you found out!
and the annoying subshell is gone for good.
1: The notation as grep "[y]ad"
instead of simply grep yad
prevents the grep
process itself from showing up in the results list.
If you have the terminal still open
bash
provides the variable $!
, which âÂÂexpands to the process ID of the job most recently placed into the backgroundâÂÂ, so the following just kills the latest process in the background:
kill $!
If it's not the latest process, just can get a list of running jobs with the jobs
builtin, example output:
[1]- Running while true; do
yad; sleep 60;
done &
[2]+ Stopped sleep 10
There are two jobs in the job list, to kill one of them you can access it with the job number or the shortcuts %
, %+
(âÂÂcurrent jobâÂÂ) and %-
(âÂÂprevious jobâÂÂ), e.g. to kill the loop running in the background you could do
kill %1 # or
kill %-
and to kill the suspended sleep 10
job:
kill %2 # or
kill %+ # or
kill %
add a comment |Â
up vote
33
down vote
accepted
I started
while true; do yad; sleep 60; done &
and closed the terminal to test it, now I got the same problem.
If you already closed the terminal you've started the loop in
Let's get an overview of running processes with ps fjx
, the last lines on my machine read
2226 11606 11606 19337 ? -1 S 1000 0:00 _ /bin/bash
11606 22485 11606 19337 ? -1 S 1000 0:00 | _ sleep 10
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
1 2215 2215 2215 ? -1 Ss 1000 0:00 /lib/systemd/systemd --user
2215 2216 2215 2215 ? -1 S 1000 0:00 _ (sd-pam)
You can see yad
as a subprocess of /bin/bash
, if I close yad
it changes to sleep 60
in the output of ps
. If the tree view is too confusing you can also search the output as follows1:
ps fjx | grep "[y]ad" # or respectively
ps fjx | grep "[s]leep 60"
The output lines begin with two numbers, the first being the PPID, the process ID of the parent process and the second being the PID, the ID of the process itself. It's because of that 9411
appears in both rows here:
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
That's the bash
subshell we want to kill and we just found out its PID, so now everything that remains is a simple
kill 9411 # replace 9411 with the PID you found out!
and the annoying subshell is gone for good.
1: The notation as grep "[y]ad"
instead of simply grep yad
prevents the grep
process itself from showing up in the results list.
If you have the terminal still open
bash
provides the variable $!
, which âÂÂexpands to the process ID of the job most recently placed into the backgroundâÂÂ, so the following just kills the latest process in the background:
kill $!
If it's not the latest process, just can get a list of running jobs with the jobs
builtin, example output:
[1]- Running while true; do
yad; sleep 60;
done &
[2]+ Stopped sleep 10
There are two jobs in the job list, to kill one of them you can access it with the job number or the shortcuts %
, %+
(âÂÂcurrent jobâÂÂ) and %-
(âÂÂprevious jobâÂÂ), e.g. to kill the loop running in the background you could do
kill %1 # or
kill %-
and to kill the suspended sleep 10
job:
kill %2 # or
kill %+ # or
kill %
add a comment |Â
up vote
33
down vote
accepted
up vote
33
down vote
accepted
I started
while true; do yad; sleep 60; done &
and closed the terminal to test it, now I got the same problem.
If you already closed the terminal you've started the loop in
Let's get an overview of running processes with ps fjx
, the last lines on my machine read
2226 11606 11606 19337 ? -1 S 1000 0:00 _ /bin/bash
11606 22485 11606 19337 ? -1 S 1000 0:00 | _ sleep 10
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
1 2215 2215 2215 ? -1 Ss 1000 0:00 /lib/systemd/systemd --user
2215 2216 2215 2215 ? -1 S 1000 0:00 _ (sd-pam)
You can see yad
as a subprocess of /bin/bash
, if I close yad
it changes to sleep 60
in the output of ps
. If the tree view is too confusing you can also search the output as follows1:
ps fjx | grep "[y]ad" # or respectively
ps fjx | grep "[s]leep 60"
The output lines begin with two numbers, the first being the PPID, the process ID of the parent process and the second being the PID, the ID of the process itself. It's because of that 9411
appears in both rows here:
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
That's the bash
subshell we want to kill and we just found out its PID, so now everything that remains is a simple
kill 9411 # replace 9411 with the PID you found out!
and the annoying subshell is gone for good.
1: The notation as grep "[y]ad"
instead of simply grep yad
prevents the grep
process itself from showing up in the results list.
If you have the terminal still open
bash
provides the variable $!
, which âÂÂexpands to the process ID of the job most recently placed into the backgroundâÂÂ, so the following just kills the latest process in the background:
kill $!
If it's not the latest process, just can get a list of running jobs with the jobs
builtin, example output:
[1]- Running while true; do
yad; sleep 60;
done &
[2]+ Stopped sleep 10
There are two jobs in the job list, to kill one of them you can access it with the job number or the shortcuts %
, %+
(âÂÂcurrent jobâÂÂ) and %-
(âÂÂprevious jobâÂÂ), e.g. to kill the loop running in the background you could do
kill %1 # or
kill %-
and to kill the suspended sleep 10
job:
kill %2 # or
kill %+ # or
kill %
I started
while true; do yad; sleep 60; done &
and closed the terminal to test it, now I got the same problem.
If you already closed the terminal you've started the loop in
Let's get an overview of running processes with ps fjx
, the last lines on my machine read
2226 11606 11606 19337 ? -1 S 1000 0:00 _ /bin/bash
11606 22485 11606 19337 ? -1 S 1000 0:00 | _ sleep 10
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
1 2215 2215 2215 ? -1 Ss 1000 0:00 /lib/systemd/systemd --user
2215 2216 2215 2215 ? -1 S 1000 0:00 _ (sd-pam)
You can see yad
as a subprocess of /bin/bash
, if I close yad
it changes to sleep 60
in the output of ps
. If the tree view is too confusing you can also search the output as follows1:
ps fjx | grep "[y]ad" # or respectively
ps fjx | grep "[s]leep 60"
The output lines begin with two numbers, the first being the PPID, the process ID of the parent process and the second being the PID, the ID of the process itself. It's because of that 9411
appears in both rows here:
2226 9411 9411 8383 ? -1 S 1000 0:00 _ /bin/bash
9411 17674 9411 8383 ? -1 Sl 1000 0:00 _ yad
That's the bash
subshell we want to kill and we just found out its PID, so now everything that remains is a simple
kill 9411 # replace 9411 with the PID you found out!
and the annoying subshell is gone for good.
1: The notation as grep "[y]ad"
instead of simply grep yad
prevents the grep
process itself from showing up in the results list.
If you have the terminal still open
bash
provides the variable $!
, which âÂÂexpands to the process ID of the job most recently placed into the backgroundâÂÂ, so the following just kills the latest process in the background:
kill $!
If it's not the latest process, just can get a list of running jobs with the jobs
builtin, example output:
[1]- Running while true; do
yad; sleep 60;
done &
[2]+ Stopped sleep 10
There are two jobs in the job list, to kill one of them you can access it with the job number or the shortcuts %
, %+
(âÂÂcurrent jobâÂÂ) and %-
(âÂÂprevious jobâÂÂ), e.g. to kill the loop running in the background you could do
kill %1 # or
kill %-
and to kill the suspended sleep 10
job:
kill %2 # or
kill %+ # or
kill %
edited May 9 at 13:31
answered May 9 at 6:47
![](https://i.stack.imgur.com/9L8vd.png?s=32&g=1)
![](https://i.stack.imgur.com/9L8vd.png?s=32&g=1)
dessert
19.6k55594
19.6k55594
add a comment |Â
add a comment |Â
up vote
5
down vote
I need to note that when you close the terminal where you entered that command, the sub-command should've died along with it. Trying to reproduce this showed this behavior.
Now, assuming that you indeed are in a situation where this didn't happen, one way to go about killing the program you left running in the background, which was caused by the &
at the end of the command, is as follows:
- Open a new shell and run
echo $$
to note your current PID (process ID), so that you don't kill your own session. - Identify the PID of the program you think is still running; you can do this using the
ps -ef | grep $SHELL
command to find which programs are running a shell. - Note the 2nd column from the left and note the numeric value that differs from your
echo $$
result above; this is the PID you want to kill. - Run the
kill -SIGTERM <pid>
command, where<pid>
is the numeric value you identified in step #3 - Confirm the program is no longer running by repeating step #2
You could also restart your session or your computer, but the above will allow you to avoid that.
1
You could also usetop
to kill the process by pressingk
, then entering the PID, then pressing enter twice.
â luk3yx
May 9 at 6:19
add a comment |Â
up vote
5
down vote
I need to note that when you close the terminal where you entered that command, the sub-command should've died along with it. Trying to reproduce this showed this behavior.
Now, assuming that you indeed are in a situation where this didn't happen, one way to go about killing the program you left running in the background, which was caused by the &
at the end of the command, is as follows:
- Open a new shell and run
echo $$
to note your current PID (process ID), so that you don't kill your own session. - Identify the PID of the program you think is still running; you can do this using the
ps -ef | grep $SHELL
command to find which programs are running a shell. - Note the 2nd column from the left and note the numeric value that differs from your
echo $$
result above; this is the PID you want to kill. - Run the
kill -SIGTERM <pid>
command, where<pid>
is the numeric value you identified in step #3 - Confirm the program is no longer running by repeating step #2
You could also restart your session or your computer, but the above will allow you to avoid that.
1
You could also usetop
to kill the process by pressingk
, then entering the PID, then pressing enter twice.
â luk3yx
May 9 at 6:19
add a comment |Â
up vote
5
down vote
up vote
5
down vote
I need to note that when you close the terminal where you entered that command, the sub-command should've died along with it. Trying to reproduce this showed this behavior.
Now, assuming that you indeed are in a situation where this didn't happen, one way to go about killing the program you left running in the background, which was caused by the &
at the end of the command, is as follows:
- Open a new shell and run
echo $$
to note your current PID (process ID), so that you don't kill your own session. - Identify the PID of the program you think is still running; you can do this using the
ps -ef | grep $SHELL
command to find which programs are running a shell. - Note the 2nd column from the left and note the numeric value that differs from your
echo $$
result above; this is the PID you want to kill. - Run the
kill -SIGTERM <pid>
command, where<pid>
is the numeric value you identified in step #3 - Confirm the program is no longer running by repeating step #2
You could also restart your session or your computer, but the above will allow you to avoid that.
I need to note that when you close the terminal where you entered that command, the sub-command should've died along with it. Trying to reproduce this showed this behavior.
Now, assuming that you indeed are in a situation where this didn't happen, one way to go about killing the program you left running in the background, which was caused by the &
at the end of the command, is as follows:
- Open a new shell and run
echo $$
to note your current PID (process ID), so that you don't kill your own session. - Identify the PID of the program you think is still running; you can do this using the
ps -ef | grep $SHELL
command to find which programs are running a shell. - Note the 2nd column from the left and note the numeric value that differs from your
echo $$
result above; this is the PID you want to kill. - Run the
kill -SIGTERM <pid>
command, where<pid>
is the numeric value you identified in step #3 - Confirm the program is no longer running by repeating step #2
You could also restart your session or your computer, but the above will allow you to avoid that.
edited May 9 at 6:39
answered May 9 at 6:05
![](https://i.stack.imgur.com/USV9e.jpg?s=32&g=1)
![](https://i.stack.imgur.com/USV9e.jpg?s=32&g=1)
code_dredd
4991413
4991413
1
You could also usetop
to kill the process by pressingk
, then entering the PID, then pressing enter twice.
â luk3yx
May 9 at 6:19
add a comment |Â
1
You could also usetop
to kill the process by pressingk
, then entering the PID, then pressing enter twice.
â luk3yx
May 9 at 6:19
1
1
You could also use
top
to kill the process by pressing k
, then entering the PID, then pressing enter twice.â luk3yx
May 9 at 6:19
You could also use
top
to kill the process by pressing k
, then entering the PID, then pressing enter twice.â luk3yx
May 9 at 6:19
add a comment |Â
up vote
-1
down vote
The &
will make the terminal create a new process and get your code to run inside it. So your code becomes independent from the terminal process. Even if you close the terminal the newly process in which your code is running won't stop. So either remove &
or do ps -aux
, locate your process and kill it kill (process id)
.
add a comment |Â
up vote
-1
down vote
The &
will make the terminal create a new process and get your code to run inside it. So your code becomes independent from the terminal process. Even if you close the terminal the newly process in which your code is running won't stop. So either remove &
or do ps -aux
, locate your process and kill it kill (process id)
.
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
The &
will make the terminal create a new process and get your code to run inside it. So your code becomes independent from the terminal process. Even if you close the terminal the newly process in which your code is running won't stop. So either remove &
or do ps -aux
, locate your process and kill it kill (process id)
.
The &
will make the terminal create a new process and get your code to run inside it. So your code becomes independent from the terminal process. Even if you close the terminal the newly process in which your code is running won't stop. So either remove &
or do ps -aux
, locate your process and kill it kill (process id)
.
edited May 9 at 22:42
![](https://i.stack.imgur.com/WwSSv.jpg?s=32&g=1)
![](https://i.stack.imgur.com/WwSSv.jpg?s=32&g=1)
ubashu
2,23721736
2,23721736
answered May 9 at 21:56
![](https://i.stack.imgur.com/Jk9UU.jpg?s=32&g=1)
![](https://i.stack.imgur.com/Jk9UU.jpg?s=32&g=1)
Dr4ke the b4dass
11
11
add a comment |Â
add a comment |Â
up vote
-3
down vote
Usually bg for background fg for foreground. If you use & symbol use fg it will show the current running program. Press Ctrl+C to kill.
3
Usingbg
/fg
won't work once terminal is detached frombash
. Would be unable to reattach usingreptyr
becausebash
has child processes (sleep
).
â xiota
May 9 at 7:04
He closed terminal because he will kill that process. So next time he will use fg to close the program. Simple
â Curious
May 9 at 9:28
@Curious that's next time. But OP is asking about this time.
â RonJohn
May 9 at 22:35
add a comment |Â
up vote
-3
down vote
Usually bg for background fg for foreground. If you use & symbol use fg it will show the current running program. Press Ctrl+C to kill.
3
Usingbg
/fg
won't work once terminal is detached frombash
. Would be unable to reattach usingreptyr
becausebash
has child processes (sleep
).
â xiota
May 9 at 7:04
He closed terminal because he will kill that process. So next time he will use fg to close the program. Simple
â Curious
May 9 at 9:28
@Curious that's next time. But OP is asking about this time.
â RonJohn
May 9 at 22:35
add a comment |Â
up vote
-3
down vote
up vote
-3
down vote
Usually bg for background fg for foreground. If you use & symbol use fg it will show the current running program. Press Ctrl+C to kill.
Usually bg for background fg for foreground. If you use & symbol use fg it will show the current running program. Press Ctrl+C to kill.
answered May 9 at 6:54
![](https://lh5.googleusercontent.com/-QEhL0HYTD0g/AAAAAAAAAAI/AAAAAAAAAg4/pakTl_biv-8/photo.jpg?sz=32)
![](https://lh5.googleusercontent.com/-QEhL0HYTD0g/AAAAAAAAAAI/AAAAAAAAAg4/pakTl_biv-8/photo.jpg?sz=32)
Curious
53
53
3
Usingbg
/fg
won't work once terminal is detached frombash
. Would be unable to reattach usingreptyr
becausebash
has child processes (sleep
).
â xiota
May 9 at 7:04
He closed terminal because he will kill that process. So next time he will use fg to close the program. Simple
â Curious
May 9 at 9:28
@Curious that's next time. But OP is asking about this time.
â RonJohn
May 9 at 22:35
add a comment |Â
3
Usingbg
/fg
won't work once terminal is detached frombash
. Would be unable to reattach usingreptyr
becausebash
has child processes (sleep
).
â xiota
May 9 at 7:04
He closed terminal because he will kill that process. So next time he will use fg to close the program. Simple
â Curious
May 9 at 9:28
@Curious that's next time. But OP is asking about this time.
â RonJohn
May 9 at 22:35
3
3
Using
bg
/fg
won't work once terminal is detached from bash
. Would be unable to reattach using reptyr
because bash
has child processes (sleep
).â xiota
May 9 at 7:04
Using
bg
/fg
won't work once terminal is detached from bash
. Would be unable to reattach using reptyr
because bash
has child processes (sleep
).â xiota
May 9 at 7:04
He closed terminal because he will kill that process. So next time he will use fg to close the program. Simple
â Curious
May 9 at 9:28
He closed terminal because he will kill that process. So next time he will use fg to close the program. Simple
â Curious
May 9 at 9:28
@Curious that's next time. But OP is asking about this time.
â RonJohn
May 9 at 22:35
@Curious that's next time. But OP is asking about this time.
â RonJohn
May 9 at 22:35
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1033866%2fhow-to-stop-a-bash-while-loop-running-in-the-background%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password