Why can't I get pgrep output right to variable on bash script?












3















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









share|improve this question









New contributor




Tube is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1





    0 or 1 is exit status, but $(...) captures output.

    – Charles Duffy
    2 days ago











  • grab $? . do man bash.

    – user2497
    2 days ago
















3















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









share|improve this question









New contributor




Tube is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1





    0 or 1 is exit status, but $(...) captures output.

    – Charles Duffy
    2 days ago











  • grab $? . do man bash.

    – user2497
    2 days ago














3












3








3








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









share|improve this question









New contributor




Tube is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












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






share|improve this question









New contributor




Tube is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Tube is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 2 days ago









Kusalananda

137k17258426




137k17258426






New contributor




Tube is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Mar 19 at 21:04









TubeTube

161




161




New contributor




Tube is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Tube is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Tube is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 1





    0 or 1 is exit status, but $(...) captures output.

    – Charles Duffy
    2 days ago











  • grab $? . do man bash.

    – user2497
    2 days ago














  • 1





    0 or 1 is exit status, but $(...) captures output.

    – Charles Duffy
    2 days ago











  • grab $? . do man bash.

    – user2497
    2 days ago








1




1





0 or 1 is exit status, but $(...) captures output.

– Charles Duffy
2 days ago





0 or 1 is exit status, but $(...) captures output.

– Charles Duffy
2 days ago













grab $? . do man bash.

– user2497
2 days ago





grab $? . do man bash.

– user2497
2 days ago










2 Answers
2






active

oldest

votes


















7














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 several compton processes that have now been killed, or at least signalled, and exec compton -b will not be executed.


  • If pkill compton fails (no process matched the name, or there was some internal error in pkill), the body of the if statement would call your exec compton -b, which would replace the shell process with that of compton -b.







share|improve this answer

































    4














    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





    share|improve this answer



















    • 3





      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
      2 days ago













    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.










    draft saved

    draft discarded


















    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









    7














    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 several compton processes that have now been killed, or at least signalled, and exec compton -b will not be executed.


    • If pkill compton fails (no process matched the name, or there was some internal error in pkill), the body of the if statement would call your exec compton -b, which would replace the shell process with that of compton -b.







    share|improve this answer






























      7














      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 several compton processes that have now been killed, or at least signalled, and exec compton -b will not be executed.


      • If pkill compton fails (no process matched the name, or there was some internal error in pkill), the body of the if statement would call your exec compton -b, which would replace the shell process with that of compton -b.







      share|improve this answer




























        7












        7








        7







        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 several compton processes that have now been killed, or at least signalled, and exec compton -b will not be executed.


        • If pkill compton fails (no process matched the name, or there was some internal error in pkill), the body of the if statement would call your exec compton -b, which would replace the shell process with that of compton -b.







        share|improve this answer















        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 several compton processes that have now been killed, or at least signalled, and exec compton -b will not be executed.


        • If pkill compton fails (no process matched the name, or there was some internal error in pkill), the body of the if statement would call your exec compton -b, which would replace the shell process with that of compton -b.








        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 2 days ago

























        answered Mar 19 at 22:00









        KusalanandaKusalananda

        137k17258426




        137k17258426

























            4














            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





            share|improve this answer



















            • 3





              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
              2 days ago


















            4














            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





            share|improve this answer



















            • 3





              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
              2 days ago
















            4












            4








            4







            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





            share|improve this answer













            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






            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Mar 19 at 21:23









            Jakub JindraJakub Jindra

            389310




            389310








            • 3





              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
              2 days ago
















            • 3





              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
              2 days ago










            3




            3





            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
            2 days 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
            2 days ago












            Tube is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Plaza Victoria

            Puebla de Zaragoza

            Musa