Why can't I get pgrep output right to variable on bash script?
I'm trying to make a script to either quit compton if it's running or start it if it's not running. I've read from man that it should exit 1 if process is found, so I've tried to make a script that uses that... However this just doesn't work, It starts if it's closed but doesn't close it. what am I doing wrong ??
#!/bin/bash
status=$(pgrep compton 2>&1)
if [[ $status == 1 ]];
then
killall compton
else
exec compton -b
fi
echo $status
bash stdout stderr exit-status pgrep
New contributor
add a comment |
I'm trying to make a script to either quit compton if it's running or start it if it's not running. I've read from man that it should exit 1 if process is found, so I've tried to make a script that uses that... However this just doesn't work, It starts if it's closed but doesn't close it. what am I doing wrong ??
#!/bin/bash
status=$(pgrep compton 2>&1)
if [[ $status == 1 ]];
then
killall compton
else
exec compton -b
fi
echo $status
bash stdout stderr exit-status pgrep
New contributor
0
or1
is exit status, but$(...)
captures output.
– Charles Duffy
6 hours ago
add a comment |
I'm trying to make a script to either quit compton if it's running or start it if it's not running. I've read from man that it should exit 1 if process is found, so I've tried to make a script that uses that... However this just doesn't work, It starts if it's closed but doesn't close it. what am I doing wrong ??
#!/bin/bash
status=$(pgrep compton 2>&1)
if [[ $status == 1 ]];
then
killall compton
else
exec compton -b
fi
echo $status
bash stdout stderr exit-status pgrep
New contributor
I'm trying to make a script to either quit compton if it's running or start it if it's not running. I've read from man that it should exit 1 if process is found, so I've tried to make a script that uses that... However this just doesn't work, It starts if it's closed but doesn't close it. what am I doing wrong ??
#!/bin/bash
status=$(pgrep compton 2>&1)
if [[ $status == 1 ]];
then
killall compton
else
exec compton -b
fi
echo $status
bash stdout stderr exit-status pgrep
bash stdout stderr exit-status pgrep
New contributor
New contributor
edited 6 hours ago
Kusalananda
136k17257426
136k17257426
New contributor
asked 8 hours ago
TubeTube
111
111
New contributor
New contributor
0
or1
is exit status, but$(...)
captures output.
– Charles Duffy
6 hours ago
add a comment |
0
or1
is exit status, but$(...)
captures output.
– Charles Duffy
6 hours ago
0
or 1
is exit status, but $(...)
captures output.– Charles Duffy
6 hours ago
0
or 1
is exit status, but $(...)
captures output.– Charles Duffy
6 hours ago
add a comment |
2 Answers
2
active
oldest
votes
You are getting the pgrep
output in your status
variable. It's just not the output that you expect it to be.
pgrep
outputs the process IDs (PIDs) of the processes matching the pattern that you give it. If there is a process whose name matches compton
, then $status
would be the PID of that process, or of those processes. pgrep
also returns an exit status, but an exit status is not captured by a command substitution as a string.
In your test, you compare $status
against 1
. It is unlikely that compton
has PID 1.
If you want to kill any compton
process if they exist, and start compton -b
if no compton
process exists, you may do that with
#!/bin/sh
if ! pkill compton; then
exec compton -b
fi
This uses the exit status of pkill
. The pkill
tool works in an equivalent way to pgrep
(they are usually distributed and installed as a pair) but instead of outputting PIDs of matching processes like pgrep
would do, pkill
sends the TERM
signal (by default) to the matching processes.
The if
keyword uses the exit status of the command that you use with it.
The !
inverts the sense of the test so that
If
pkill compton
succeeds, it means that there was one or severalcompton
processes that have now been killed, or at least signalled, andexec compton -b
will not be executed.If
pkill compton
fails (no process matched the name, or there was some internal error inpkill
), the body of theif
statement would call yourexec compton -b
, which would replace the shell process with that ofcompton -b
.
add a comment |
You should control exit status of pgrep process which will be in $? variable. Or check if $status variable where you're storing the output of pgrep is f.e. non zero-length string. The script in the question checks whether string in variable status is "1"
so
#!/bin/bash
pgrep compton >/dev/null
if [[ $? -eq 0 ]]
then
killall compton
else
exec compton -b
fi
or
#!/bin/bash
status=$(pgrep compton 2>&1)
if [[ -n "$status" ]]
then
killall compton
else
exec compton -b
fi
if pgrep compton >/dev/null; then
is the better practice, so one doesn't directly inspect$?
at all. In addition to avoiding bugs where$?
refers to a different command than you think it does when editing code to add logging or such, this also means thatset -e
will no longer treatpgrep
returning 1 as cause to exit the script (because branching on its exit status marks it as "checked").
– Charles Duffy
6 hours ago
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
});
}
});
Tube is a new contributor. Be nice, and check out our Code of Conduct.
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%2f507290%2fwhy-cant-i-get-pgrep-output-right-to-variable-on-bash-script%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You are getting the pgrep
output in your status
variable. It's just not the output that you expect it to be.
pgrep
outputs the process IDs (PIDs) of the processes matching the pattern that you give it. If there is a process whose name matches compton
, then $status
would be the PID of that process, or of those processes. pgrep
also returns an exit status, but an exit status is not captured by a command substitution as a string.
In your test, you compare $status
against 1
. It is unlikely that compton
has PID 1.
If you want to kill any compton
process if they exist, and start compton -b
if no compton
process exists, you may do that with
#!/bin/sh
if ! pkill compton; then
exec compton -b
fi
This uses the exit status of pkill
. The pkill
tool works in an equivalent way to pgrep
(they are usually distributed and installed as a pair) but instead of outputting PIDs of matching processes like pgrep
would do, pkill
sends the TERM
signal (by default) to the matching processes.
The if
keyword uses the exit status of the command that you use with it.
The !
inverts the sense of the test so that
If
pkill compton
succeeds, it means that there was one or severalcompton
processes that have now been killed, or at least signalled, andexec compton -b
will not be executed.If
pkill compton
fails (no process matched the name, or there was some internal error inpkill
), the body of theif
statement would call yourexec compton -b
, which would replace the shell process with that ofcompton -b
.
add a comment |
You are getting the pgrep
output in your status
variable. It's just not the output that you expect it to be.
pgrep
outputs the process IDs (PIDs) of the processes matching the pattern that you give it. If there is a process whose name matches compton
, then $status
would be the PID of that process, or of those processes. pgrep
also returns an exit status, but an exit status is not captured by a command substitution as a string.
In your test, you compare $status
against 1
. It is unlikely that compton
has PID 1.
If you want to kill any compton
process if they exist, and start compton -b
if no compton
process exists, you may do that with
#!/bin/sh
if ! pkill compton; then
exec compton -b
fi
This uses the exit status of pkill
. The pkill
tool works in an equivalent way to pgrep
(they are usually distributed and installed as a pair) but instead of outputting PIDs of matching processes like pgrep
would do, pkill
sends the TERM
signal (by default) to the matching processes.
The if
keyword uses the exit status of the command that you use with it.
The !
inverts the sense of the test so that
If
pkill compton
succeeds, it means that there was one or severalcompton
processes that have now been killed, or at least signalled, andexec compton -b
will not be executed.If
pkill compton
fails (no process matched the name, or there was some internal error inpkill
), the body of theif
statement would call yourexec compton -b
, which would replace the shell process with that ofcompton -b
.
add a comment |
You are getting the pgrep
output in your status
variable. It's just not the output that you expect it to be.
pgrep
outputs the process IDs (PIDs) of the processes matching the pattern that you give it. If there is a process whose name matches compton
, then $status
would be the PID of that process, or of those processes. pgrep
also returns an exit status, but an exit status is not captured by a command substitution as a string.
In your test, you compare $status
against 1
. It is unlikely that compton
has PID 1.
If you want to kill any compton
process if they exist, and start compton -b
if no compton
process exists, you may do that with
#!/bin/sh
if ! pkill compton; then
exec compton -b
fi
This uses the exit status of pkill
. The pkill
tool works in an equivalent way to pgrep
(they are usually distributed and installed as a pair) but instead of outputting PIDs of matching processes like pgrep
would do, pkill
sends the TERM
signal (by default) to the matching processes.
The if
keyword uses the exit status of the command that you use with it.
The !
inverts the sense of the test so that
If
pkill compton
succeeds, it means that there was one or severalcompton
processes that have now been killed, or at least signalled, andexec compton -b
will not be executed.If
pkill compton
fails (no process matched the name, or there was some internal error inpkill
), the body of theif
statement would call yourexec compton -b
, which would replace the shell process with that ofcompton -b
.
You are getting the pgrep
output in your status
variable. It's just not the output that you expect it to be.
pgrep
outputs the process IDs (PIDs) of the processes matching the pattern that you give it. If there is a process whose name matches compton
, then $status
would be the PID of that process, or of those processes. pgrep
also returns an exit status, but an exit status is not captured by a command substitution as a string.
In your test, you compare $status
against 1
. It is unlikely that compton
has PID 1.
If you want to kill any compton
process if they exist, and start compton -b
if no compton
process exists, you may do that with
#!/bin/sh
if ! pkill compton; then
exec compton -b
fi
This uses the exit status of pkill
. The pkill
tool works in an equivalent way to pgrep
(they are usually distributed and installed as a pair) but instead of outputting PIDs of matching processes like pgrep
would do, pkill
sends the TERM
signal (by default) to the matching processes.
The if
keyword uses the exit status of the command that you use with it.
The !
inverts the sense of the test so that
If
pkill compton
succeeds, it means that there was one or severalcompton
processes that have now been killed, or at least signalled, andexec compton -b
will not be executed.If
pkill compton
fails (no process matched the name, or there was some internal error inpkill
), the body of theif
statement would call yourexec compton -b
, which would replace the shell process with that ofcompton -b
.
edited 6 hours ago
answered 7 hours ago
KusalanandaKusalananda
136k17257426
136k17257426
add a comment |
add a comment |
You should control exit status of pgrep process which will be in $? variable. Or check if $status variable where you're storing the output of pgrep is f.e. non zero-length string. The script in the question checks whether string in variable status is "1"
so
#!/bin/bash
pgrep compton >/dev/null
if [[ $? -eq 0 ]]
then
killall compton
else
exec compton -b
fi
or
#!/bin/bash
status=$(pgrep compton 2>&1)
if [[ -n "$status" ]]
then
killall compton
else
exec compton -b
fi
if pgrep compton >/dev/null; then
is the better practice, so one doesn't directly inspect$?
at all. In addition to avoiding bugs where$?
refers to a different command than you think it does when editing code to add logging or such, this also means thatset -e
will no longer treatpgrep
returning 1 as cause to exit the script (because branching on its exit status marks it as "checked").
– Charles Duffy
6 hours ago
add a comment |
You should control exit status of pgrep process which will be in $? variable. Or check if $status variable where you're storing the output of pgrep is f.e. non zero-length string. The script in the question checks whether string in variable status is "1"
so
#!/bin/bash
pgrep compton >/dev/null
if [[ $? -eq 0 ]]
then
killall compton
else
exec compton -b
fi
or
#!/bin/bash
status=$(pgrep compton 2>&1)
if [[ -n "$status" ]]
then
killall compton
else
exec compton -b
fi
if pgrep compton >/dev/null; then
is the better practice, so one doesn't directly inspect$?
at all. In addition to avoiding bugs where$?
refers to a different command than you think it does when editing code to add logging or such, this also means thatset -e
will no longer treatpgrep
returning 1 as cause to exit the script (because branching on its exit status marks it as "checked").
– Charles Duffy
6 hours ago
add a comment |
You should control exit status of pgrep process which will be in $? variable. Or check if $status variable where you're storing the output of pgrep is f.e. non zero-length string. The script in the question checks whether string in variable status is "1"
so
#!/bin/bash
pgrep compton >/dev/null
if [[ $? -eq 0 ]]
then
killall compton
else
exec compton -b
fi
or
#!/bin/bash
status=$(pgrep compton 2>&1)
if [[ -n "$status" ]]
then
killall compton
else
exec compton -b
fi
You should control exit status of pgrep process which will be in $? variable. Or check if $status variable where you're storing the output of pgrep is f.e. non zero-length string. The script in the question checks whether string in variable status is "1"
so
#!/bin/bash
pgrep compton >/dev/null
if [[ $? -eq 0 ]]
then
killall compton
else
exec compton -b
fi
or
#!/bin/bash
status=$(pgrep compton 2>&1)
if [[ -n "$status" ]]
then
killall compton
else
exec compton -b
fi
answered 8 hours ago
Jakub JindraJakub Jindra
317310
317310
if pgrep compton >/dev/null; then
is the better practice, so one doesn't directly inspect$?
at all. In addition to avoiding bugs where$?
refers to a different command than you think it does when editing code to add logging or such, this also means thatset -e
will no longer treatpgrep
returning 1 as cause to exit the script (because branching on its exit status marks it as "checked").
– Charles Duffy
6 hours ago
add a comment |
if pgrep compton >/dev/null; then
is the better practice, so one doesn't directly inspect$?
at all. In addition to avoiding bugs where$?
refers to a different command than you think it does when editing code to add logging or such, this also means thatset -e
will no longer treatpgrep
returning 1 as cause to exit the script (because branching on its exit status marks it as "checked").
– Charles Duffy
6 hours ago
if pgrep compton >/dev/null; then
is the better practice, so one doesn't directly inspect $?
at all. In addition to avoiding bugs where $?
refers to a different command than you think it does when editing code to add logging or such, this also means that set -e
will no longer treat pgrep
returning 1 as cause to exit the script (because branching on its exit status marks it as "checked").– Charles Duffy
6 hours ago
if pgrep compton >/dev/null; then
is the better practice, so one doesn't directly inspect $?
at all. In addition to avoiding bugs where $?
refers to a different command than you think it does when editing code to add logging or such, this also means that set -e
will no longer treat pgrep
returning 1 as cause to exit the script (because branching on its exit status marks it as "checked").– Charles Duffy
6 hours ago
add a comment |
Tube is a new contributor. Be nice, and check out our Code of Conduct.
Tube is a new contributor. Be nice, and check out our Code of Conduct.
Tube is a new contributor. Be nice, and check out our Code of Conduct.
Tube is a new contributor. Be nice, and check out our Code of Conduct.
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.
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%2f507290%2fwhy-cant-i-get-pgrep-output-right-to-variable-on-bash-script%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
0
or1
is exit status, but$(...)
captures output.– Charles Duffy
6 hours ago