Kill all background jobs
Is there a more compact form of killing background jobs than:
for i in {1..5}; do kill %$i; done
Also, {1..5} obviously has a hard-coded magic number in it, how can I make it "N" with N being the right number, without doing a:
$(jobs | wc -l)
I actually use j in PS1 to get the # of managed jobs, is this equivalent?
bash
|
show 1 more comment
Is there a more compact form of killing background jobs than:
for i in {1..5}; do kill %$i; done
Also, {1..5} obviously has a hard-coded magic number in it, how can I make it "N" with N being the right number, without doing a:
$(jobs | wc -l)
I actually use j in PS1 to get the # of managed jobs, is this equivalent?
bash
3
kill $(jobs -p)seems easier.
– jw013
Jul 19 '12 at 22:00
I would prefer to kill jobs individually, if possible. (I might have misunderstood your comment, though)
– Robottinosino
Jul 19 '12 at 22:12
for pid in $(jobs -p); do kill $pid; done?
– jw013
Jul 19 '12 at 22:27
2
@jw013 It's not only easier, it's actually correct (please post it as an answer), unlike a solution based on counting the lines of the output ofjobswhich only works if the jobs happen to be numbered consecutively. Oh, and “kill jobs individually” is meaningless: passing multiple PIDs to thekillcommand does exactly the same thing as passing them separately.
– Gilles
Jul 19 '12 at 23:52
I was entering the command incorrectly, kill $(jobs -p) words and looks very correct to me too. Ready to accept.
– Robottinosino
Jul 20 '12 at 0:31
|
show 1 more comment
Is there a more compact form of killing background jobs than:
for i in {1..5}; do kill %$i; done
Also, {1..5} obviously has a hard-coded magic number in it, how can I make it "N" with N being the right number, without doing a:
$(jobs | wc -l)
I actually use j in PS1 to get the # of managed jobs, is this equivalent?
bash
Is there a more compact form of killing background jobs than:
for i in {1..5}; do kill %$i; done
Also, {1..5} obviously has a hard-coded magic number in it, how can I make it "N" with N being the right number, without doing a:
$(jobs | wc -l)
I actually use j in PS1 to get the # of managed jobs, is this equivalent?
bash
bash
edited Jan 28 '16 at 1:17
Braiam
23.1k1976137
23.1k1976137
asked Jul 19 '12 at 21:49
Robottinosino
1,82382745
1,82382745
3
kill $(jobs -p)seems easier.
– jw013
Jul 19 '12 at 22:00
I would prefer to kill jobs individually, if possible. (I might have misunderstood your comment, though)
– Robottinosino
Jul 19 '12 at 22:12
for pid in $(jobs -p); do kill $pid; done?
– jw013
Jul 19 '12 at 22:27
2
@jw013 It's not only easier, it's actually correct (please post it as an answer), unlike a solution based on counting the lines of the output ofjobswhich only works if the jobs happen to be numbered consecutively. Oh, and “kill jobs individually” is meaningless: passing multiple PIDs to thekillcommand does exactly the same thing as passing them separately.
– Gilles
Jul 19 '12 at 23:52
I was entering the command incorrectly, kill $(jobs -p) words and looks very correct to me too. Ready to accept.
– Robottinosino
Jul 20 '12 at 0:31
|
show 1 more comment
3
kill $(jobs -p)seems easier.
– jw013
Jul 19 '12 at 22:00
I would prefer to kill jobs individually, if possible. (I might have misunderstood your comment, though)
– Robottinosino
Jul 19 '12 at 22:12
for pid in $(jobs -p); do kill $pid; done?
– jw013
Jul 19 '12 at 22:27
2
@jw013 It's not only easier, it's actually correct (please post it as an answer), unlike a solution based on counting the lines of the output ofjobswhich only works if the jobs happen to be numbered consecutively. Oh, and “kill jobs individually” is meaningless: passing multiple PIDs to thekillcommand does exactly the same thing as passing them separately.
– Gilles
Jul 19 '12 at 23:52
I was entering the command incorrectly, kill $(jobs -p) words and looks very correct to me too. Ready to accept.
– Robottinosino
Jul 20 '12 at 0:31
3
3
kill $(jobs -p) seems easier.– jw013
Jul 19 '12 at 22:00
kill $(jobs -p) seems easier.– jw013
Jul 19 '12 at 22:00
I would prefer to kill jobs individually, if possible. (I might have misunderstood your comment, though)
– Robottinosino
Jul 19 '12 at 22:12
I would prefer to kill jobs individually, if possible. (I might have misunderstood your comment, though)
– Robottinosino
Jul 19 '12 at 22:12
for pid in $(jobs -p); do kill $pid; done?– jw013
Jul 19 '12 at 22:27
for pid in $(jobs -p); do kill $pid; done?– jw013
Jul 19 '12 at 22:27
2
2
@jw013 It's not only easier, it's actually correct (please post it as an answer), unlike a solution based on counting the lines of the output of
jobs which only works if the jobs happen to be numbered consecutively. Oh, and “kill jobs individually” is meaningless: passing multiple PIDs to the kill command does exactly the same thing as passing them separately.– Gilles
Jul 19 '12 at 23:52
@jw013 It's not only easier, it's actually correct (please post it as an answer), unlike a solution based on counting the lines of the output of
jobs which only works if the jobs happen to be numbered consecutively. Oh, and “kill jobs individually” is meaningless: passing multiple PIDs to the kill command does exactly the same thing as passing them separately.– Gilles
Jul 19 '12 at 23:52
I was entering the command incorrectly, kill $(jobs -p) words and looks very correct to me too. Ready to accept.
– Robottinosino
Jul 20 '12 at 0:31
I was entering the command incorrectly, kill $(jobs -p) words and looks very correct to me too. Ready to accept.
– Robottinosino
Jul 20 '12 at 0:31
|
show 1 more comment
3 Answers
3
active
oldest
votes
To just kill all background jobs managed by bash, do
kill $(jobs -p)
Note that since both jobs and kill are built into bash, you shouldn't run into any errors of the Argument list too long type.
1
Also for posterity, what bahamat thinks is the way to do it inzshdisqualifies them as any authority on the topic.
– peth
Mar 8 '13 at 23:46
I feel like I should know this, but how does the '$' work here?
– fersarr
Jan 8 '15 at 17:21
1
@fersarr Here you go
– jw013
Jan 8 '15 at 21:27
@bahamat That doesn't actually work since the PID may be in field 2 or 3 depending on whether the job is one of %+ or %- or not. What works iskill %${(k)^jobdirs}, which is indeed longer; if you need to list the PIDs then you can use the even longer${${jobstates#*:*:}%%=*}.
– Gilles
Jan 28 '16 at 10:06
On CentOS, my prompt is waiting for more input>
– Janac Meena
Nov 13 '18 at 19:18
add a comment |
Use xargs instead of the $(jobs -p) subcommand, because if jobs -p is empty then the kill command will fail.
jobs -p | xargs kill
1
This has the same exact effect though , it prints the help and exits with code 123
– cat
Jun 7 '17 at 20:51
1
The the command works fine on OSX but doesn't work on Debian
– brunocascio
Jun 8 '17 at 12:23
This works great on CentOS 6
– Janac Meena
Nov 13 '18 at 19:19
add a comment |
I prefer to check if there's any jobs that exist before killing them - this way the script won't fail if there's nothing running.
It's also shorter to type. Throw this in your .bash_profile:
function killjobs () {
JOBS="$(jobs -p)";
if [ -n "${JOBS}" ]; then;
kill -KILL ${JOBS};
fi
}
Then run:
killjobs
To kill any jobs running.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f43527%2fkill-all-background-jobs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
To just kill all background jobs managed by bash, do
kill $(jobs -p)
Note that since both jobs and kill are built into bash, you shouldn't run into any errors of the Argument list too long type.
1
Also for posterity, what bahamat thinks is the way to do it inzshdisqualifies them as any authority on the topic.
– peth
Mar 8 '13 at 23:46
I feel like I should know this, but how does the '$' work here?
– fersarr
Jan 8 '15 at 17:21
1
@fersarr Here you go
– jw013
Jan 8 '15 at 21:27
@bahamat That doesn't actually work since the PID may be in field 2 or 3 depending on whether the job is one of %+ or %- or not. What works iskill %${(k)^jobdirs}, which is indeed longer; if you need to list the PIDs then you can use the even longer${${jobstates#*:*:}%%=*}.
– Gilles
Jan 28 '16 at 10:06
On CentOS, my prompt is waiting for more input>
– Janac Meena
Nov 13 '18 at 19:18
add a comment |
To just kill all background jobs managed by bash, do
kill $(jobs -p)
Note that since both jobs and kill are built into bash, you shouldn't run into any errors of the Argument list too long type.
1
Also for posterity, what bahamat thinks is the way to do it inzshdisqualifies them as any authority on the topic.
– peth
Mar 8 '13 at 23:46
I feel like I should know this, but how does the '$' work here?
– fersarr
Jan 8 '15 at 17:21
1
@fersarr Here you go
– jw013
Jan 8 '15 at 21:27
@bahamat That doesn't actually work since the PID may be in field 2 or 3 depending on whether the job is one of %+ or %- or not. What works iskill %${(k)^jobdirs}, which is indeed longer; if you need to list the PIDs then you can use the even longer${${jobstates#*:*:}%%=*}.
– Gilles
Jan 28 '16 at 10:06
On CentOS, my prompt is waiting for more input>
– Janac Meena
Nov 13 '18 at 19:18
add a comment |
To just kill all background jobs managed by bash, do
kill $(jobs -p)
Note that since both jobs and kill are built into bash, you shouldn't run into any errors of the Argument list too long type.
To just kill all background jobs managed by bash, do
kill $(jobs -p)
Note that since both jobs and kill are built into bash, you shouldn't run into any errors of the Argument list too long type.
edited Jul 24 '12 at 15:38
answered Jul 22 '12 at 16:19
jw013
36k699125
36k699125
1
Also for posterity, what bahamat thinks is the way to do it inzshdisqualifies them as any authority on the topic.
– peth
Mar 8 '13 at 23:46
I feel like I should know this, but how does the '$' work here?
– fersarr
Jan 8 '15 at 17:21
1
@fersarr Here you go
– jw013
Jan 8 '15 at 21:27
@bahamat That doesn't actually work since the PID may be in field 2 or 3 depending on whether the job is one of %+ or %- or not. What works iskill %${(k)^jobdirs}, which is indeed longer; if you need to list the PIDs then you can use the even longer${${jobstates#*:*:}%%=*}.
– Gilles
Jan 28 '16 at 10:06
On CentOS, my prompt is waiting for more input>
– Janac Meena
Nov 13 '18 at 19:18
add a comment |
1
Also for posterity, what bahamat thinks is the way to do it inzshdisqualifies them as any authority on the topic.
– peth
Mar 8 '13 at 23:46
I feel like I should know this, but how does the '$' work here?
– fersarr
Jan 8 '15 at 17:21
1
@fersarr Here you go
– jw013
Jan 8 '15 at 21:27
@bahamat That doesn't actually work since the PID may be in field 2 or 3 depending on whether the job is one of %+ or %- or not. What works iskill %${(k)^jobdirs}, which is indeed longer; if you need to list the PIDs then you can use the even longer${${jobstates#*:*:}%%=*}.
– Gilles
Jan 28 '16 at 10:06
On CentOS, my prompt is waiting for more input>
– Janac Meena
Nov 13 '18 at 19:18
1
1
Also for posterity, what bahamat thinks is the way to do it in
zsh disqualifies them as any authority on the topic.– peth
Mar 8 '13 at 23:46
Also for posterity, what bahamat thinks is the way to do it in
zsh disqualifies them as any authority on the topic.– peth
Mar 8 '13 at 23:46
I feel like I should know this, but how does the '$' work here?
– fersarr
Jan 8 '15 at 17:21
I feel like I should know this, but how does the '$' work here?
– fersarr
Jan 8 '15 at 17:21
1
1
@fersarr Here you go
– jw013
Jan 8 '15 at 21:27
@fersarr Here you go
– jw013
Jan 8 '15 at 21:27
@bahamat That doesn't actually work since the PID may be in field 2 or 3 depending on whether the job is one of %+ or %- or not. What works is
kill %${(k)^jobdirs}, which is indeed longer; if you need to list the PIDs then you can use the even longer ${${jobstates#*:*:}%%=*}.– Gilles
Jan 28 '16 at 10:06
@bahamat That doesn't actually work since the PID may be in field 2 or 3 depending on whether the job is one of %+ or %- or not. What works is
kill %${(k)^jobdirs}, which is indeed longer; if you need to list the PIDs then you can use the even longer ${${jobstates#*:*:}%%=*}.– Gilles
Jan 28 '16 at 10:06
On CentOS, my prompt is waiting for more input
>– Janac Meena
Nov 13 '18 at 19:18
On CentOS, my prompt is waiting for more input
>– Janac Meena
Nov 13 '18 at 19:18
add a comment |
Use xargs instead of the $(jobs -p) subcommand, because if jobs -p is empty then the kill command will fail.
jobs -p | xargs kill
1
This has the same exact effect though , it prints the help and exits with code 123
– cat
Jun 7 '17 at 20:51
1
The the command works fine on OSX but doesn't work on Debian
– brunocascio
Jun 8 '17 at 12:23
This works great on CentOS 6
– Janac Meena
Nov 13 '18 at 19:19
add a comment |
Use xargs instead of the $(jobs -p) subcommand, because if jobs -p is empty then the kill command will fail.
jobs -p | xargs kill
1
This has the same exact effect though , it prints the help and exits with code 123
– cat
Jun 7 '17 at 20:51
1
The the command works fine on OSX but doesn't work on Debian
– brunocascio
Jun 8 '17 at 12:23
This works great on CentOS 6
– Janac Meena
Nov 13 '18 at 19:19
add a comment |
Use xargs instead of the $(jobs -p) subcommand, because if jobs -p is empty then the kill command will fail.
jobs -p | xargs kill
Use xargs instead of the $(jobs -p) subcommand, because if jobs -p is empty then the kill command will fail.
jobs -p | xargs kill
edited 1 hour ago
Taavi
32
32
answered Nov 22 '16 at 18:54
brunocascio
20923
20923
1
This has the same exact effect though , it prints the help and exits with code 123
– cat
Jun 7 '17 at 20:51
1
The the command works fine on OSX but doesn't work on Debian
– brunocascio
Jun 8 '17 at 12:23
This works great on CentOS 6
– Janac Meena
Nov 13 '18 at 19:19
add a comment |
1
This has the same exact effect though , it prints the help and exits with code 123
– cat
Jun 7 '17 at 20:51
1
The the command works fine on OSX but doesn't work on Debian
– brunocascio
Jun 8 '17 at 12:23
This works great on CentOS 6
– Janac Meena
Nov 13 '18 at 19:19
1
1
This has the same exact effect though , it prints the help and exits with code 123
– cat
Jun 7 '17 at 20:51
This has the same exact effect though , it prints the help and exits with code 123
– cat
Jun 7 '17 at 20:51
1
1
The the command works fine on OSX but doesn't work on Debian
– brunocascio
Jun 8 '17 at 12:23
The the command works fine on OSX but doesn't work on Debian
– brunocascio
Jun 8 '17 at 12:23
This works great on CentOS 6
– Janac Meena
Nov 13 '18 at 19:19
This works great on CentOS 6
– Janac Meena
Nov 13 '18 at 19:19
add a comment |
I prefer to check if there's any jobs that exist before killing them - this way the script won't fail if there's nothing running.
It's also shorter to type. Throw this in your .bash_profile:
function killjobs () {
JOBS="$(jobs -p)";
if [ -n "${JOBS}" ]; then;
kill -KILL ${JOBS};
fi
}
Then run:
killjobs
To kill any jobs running.
add a comment |
I prefer to check if there's any jobs that exist before killing them - this way the script won't fail if there's nothing running.
It's also shorter to type. Throw this in your .bash_profile:
function killjobs () {
JOBS="$(jobs -p)";
if [ -n "${JOBS}" ]; then;
kill -KILL ${JOBS};
fi
}
Then run:
killjobs
To kill any jobs running.
add a comment |
I prefer to check if there's any jobs that exist before killing them - this way the script won't fail if there's nothing running.
It's also shorter to type. Throw this in your .bash_profile:
function killjobs () {
JOBS="$(jobs -p)";
if [ -n "${JOBS}" ]; then;
kill -KILL ${JOBS};
fi
}
Then run:
killjobs
To kill any jobs running.
I prefer to check if there's any jobs that exist before killing them - this way the script won't fail if there's nothing running.
It's also shorter to type. Throw this in your .bash_profile:
function killjobs () {
JOBS="$(jobs -p)";
if [ -n "${JOBS}" ]; then;
kill -KILL ${JOBS};
fi
}
Then run:
killjobs
To kill any jobs running.
answered Feb 11 '16 at 11:04
mikemaccana
924713
924713
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f43527%2fkill-all-background-jobs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
kill $(jobs -p)seems easier.– jw013
Jul 19 '12 at 22:00
I would prefer to kill jobs individually, if possible. (I might have misunderstood your comment, though)
– Robottinosino
Jul 19 '12 at 22:12
for pid in $(jobs -p); do kill $pid; done?– jw013
Jul 19 '12 at 22:27
2
@jw013 It's not only easier, it's actually correct (please post it as an answer), unlike a solution based on counting the lines of the output of
jobswhich only works if the jobs happen to be numbered consecutively. Oh, and “kill jobs individually” is meaningless: passing multiple PIDs to thekillcommand does exactly the same thing as passing them separately.– Gilles
Jul 19 '12 at 23:52
I was entering the command incorrectly, kill $(jobs -p) words and looks very correct to me too. Ready to accept.
– Robottinosino
Jul 20 '12 at 0:31