Why can't I get pgrep output right to variable on bash script?2019 Community Moderator ElectionBash script doesn't TEE output to subdirectoryExiting a Bash script when a sudo child quitsConditional execution block with || and parentheses problemGet PID and return code from 1 line bash callWhy is “Doing an exit 130 is not the same as dying of SIGINT”?bash script: capturing tcp traffic on a remote server sometimes works, sometimes fails. No errorsWhat does typing a single exclamation mark do in Bash?Execute command and store everything to variable in bashWhy does bash 'read' exit with status 1?What does it mean when Duplicity exits with exit status 23?

Strange behavior in TikZ draw command

What do the positive and negative (+/-) transmit and receive pins mean on Ethernet cables?

Make a Bowl of Alphabet Soup

Why didn’t Eve recognize the little cockroach as a living organism?

Capacitor electron flow

What should be the ideal length of sentences in a blog post for ease of reading?

Writing in a Christian voice

How do you say "Trust your struggle." in French?

Extract substring according to regexp with sed or grep

What is the meaning of "You've never met a graph you didn't like?"

Taking the numerator and the denominator

Asserting that Atheism and Theism are both faith based positions

Pre-Employment Background Check With Consent For Future Checks

Not hide and seek

Is divisi notation needed for brass or woodwind in an orchestra?

If the Dominion rule using their Jem'Hadar troops, why is their life expectancy so low?

Travelling in US for more than 90 days

Checking @@ROWCOUNT failing

Taking my research idea outside my paid job

What (if any) is the reason to buy in small local stores?

Does capillary rise violate hydrostatic paradox?

Why would five hundred and five same as one?

Are hand made posters acceptable in Academia?

Is there a distance limit for minecart tracks?



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



2019 Community Moderator ElectionBash script doesn't TEE output to subdirectoryExiting a Bash script when a sudo child quitsConditional execution block with || and parentheses problemGet PID and return code from 1 line bash callWhy is “Doing an exit 130 is not the same as dying of SIGINT”?bash script: capturing tcp traffic on a remote server sometimes works, sometimes fails. No errorsWhat does typing a single exclamation mark do in Bash?Execute command and store everything to variable in bashWhy does bash 'read' exit with status 1?What does it mean when Duplicity exits with exit status 23?










1















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.




















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

    – Charles Duffy
    8 mins ago















1















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.




















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

    – Charles Duffy
    8 mins ago













1












1








1








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 30 mins ago









Kusalananda

136k17257426




136k17257426






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









TubeTube

61




61




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.












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

    – Charles Duffy
    8 mins ago

















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

    – Charles Duffy
    8 mins ago
















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

– Charles Duffy
8 mins ago





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

– Charles Duffy
8 mins ago










2 Answers
2






active

oldest

votes


















3














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
































    2














    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























    • 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
      8 mins 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









    3














    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





























      3














      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



























        3












        3








        3







        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 38 mins ago

























        answered 1 hour ago









        KusalanandaKusalananda

        136k17257426




        136k17257426























            2














            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























            • 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
              8 mins ago
















            2














            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























            • 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
              8 mins ago














            2












            2








            2







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









            Jakub JindraJakub Jindra

            307310




            307310












            • 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
              8 mins 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
              8 mins 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
            8 mins 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
            8 mins 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

            Can not update quote_id field of “quote_item” table magento 2Magento 2.1 - We can't remove the item. (Shopping Cart doesnt allow us to remove items before becomes empty)Add value for custom quote item attribute using REST apiREST API endpoint v1/carts/cartId/items always returns error messageCorrect way to save entries to databaseHow to remove all associated quote objects of a customer completelyMagento 2 - Save value from custom input field to quote_itemGet quote_item data using quote id and product id filter in Magento 2How to set additional data to quote_item table from controller in Magento 2?What is the purpose of additional_data column in quote_item table in magento2Set Custom Price to Quote item magento2 from controller

            How to solve knockout JS error in Magento 2 Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?(Magento2) knockout.js:3012 Uncaught ReferenceError: Unable to process bindingUnable to process binding Knockout.js magento 2Cannot read property `scopeLabel` of undefined on Product Detail PageCan't get Customer Data on frontend in Magento 2Magento2 Order Summary - unable to process bindingKO templates are not loading in Magento 2.1 applicationgetting knockout js error magento 2Product grid not load -— Unable to process binding Knockout.js magento 2Product form not loaded in magento2Uncaught ReferenceError: Unable to process binding “if: function()return (isShowLegend()) ” magento 2

            Nissan Patrol Зміст Перше покоління — 4W60 (1951-1960) | Друге покоління — 60 series (1960-1980) | Третє покоління (1980–2002) | Четверте покоління — Y60 (1987–1998) | П'яте покоління — Y61 (1997–2013) | Шосте покоління — Y62 (2010- ) | Посилання | Зноски | Навігаційне менюОфіційний український сайтТест-драйв Nissan Patrol 2010 7-го поколінняNissan PatrolКак мы тестировали Nissan Patrol 2016рвиправивши або дописавши її