How can I signal a trap in “global” bash scope from function?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












2















I want to execute a trap command in "global" scope, but the signal will come from within function. Of course it is possible to declare the variable globally beforehand or use the -g declare option. But in cases where I want to source on trap that's not very practicable as shown below:



#!/bin/bash
# ./variables
declare say=hello
declare -ri times 3


and the actual script:



#!/bin/bash
# ./trapsource

setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; source ./variables' SIGUSR1


sourceVariables ()
kill -SIGUSR1 $$


setTraps
sendSignal
echo I want you to $say "hello" $times times.
printf "$sayn%.0s" $(seq 1 $times)


But without declare -g NAME, thank you.



EDIT:
Is it possible to detach the kill -s USR1 $$ part completely from the current process, so that the signal comes from 'outside'?



I tried nohup and disown without success so far.










share|improve this question




























    2















    I want to execute a trap command in "global" scope, but the signal will come from within function. Of course it is possible to declare the variable globally beforehand or use the -g declare option. But in cases where I want to source on trap that's not very practicable as shown below:



    #!/bin/bash
    # ./variables
    declare say=hello
    declare -ri times 3


    and the actual script:



    #!/bin/bash
    # ./trapsource

    setTraps ()
    trap 'echo trap called in scope $FUNCNAME[@]; source ./variables' SIGUSR1


    sourceVariables ()
    kill -SIGUSR1 $$


    setTraps
    sendSignal
    echo I want you to $say "hello" $times times.
    printf "$sayn%.0s" $(seq 1 $times)


    But without declare -g NAME, thank you.



    EDIT:
    Is it possible to detach the kill -s USR1 $$ part completely from the current process, so that the signal comes from 'outside'?



    I tried nohup and disown without success so far.










    share|improve this question


























      2












      2








      2








      I want to execute a trap command in "global" scope, but the signal will come from within function. Of course it is possible to declare the variable globally beforehand or use the -g declare option. But in cases where I want to source on trap that's not very practicable as shown below:



      #!/bin/bash
      # ./variables
      declare say=hello
      declare -ri times 3


      and the actual script:



      #!/bin/bash
      # ./trapsource

      setTraps ()
      trap 'echo trap called in scope $FUNCNAME[@]; source ./variables' SIGUSR1


      sourceVariables ()
      kill -SIGUSR1 $$


      setTraps
      sendSignal
      echo I want you to $say "hello" $times times.
      printf "$sayn%.0s" $(seq 1 $times)


      But without declare -g NAME, thank you.



      EDIT:
      Is it possible to detach the kill -s USR1 $$ part completely from the current process, so that the signal comes from 'outside'?



      I tried nohup and disown without success so far.










      share|improve this question
















      I want to execute a trap command in "global" scope, but the signal will come from within function. Of course it is possible to declare the variable globally beforehand or use the -g declare option. But in cases where I want to source on trap that's not very practicable as shown below:



      #!/bin/bash
      # ./variables
      declare say=hello
      declare -ri times 3


      and the actual script:



      #!/bin/bash
      # ./trapsource

      setTraps ()
      trap 'echo trap called in scope $FUNCNAME[@]; source ./variables' SIGUSR1


      sourceVariables ()
      kill -SIGUSR1 $$


      setTraps
      sendSignal
      echo I want you to $say "hello" $times times.
      printf "$sayn%.0s" $(seq 1 $times)


      But without declare -g NAME, thank you.



      EDIT:
      Is it possible to detach the kill -s USR1 $$ part completely from the current process, so that the signal comes from 'outside'?



      I tried nohup and disown without success so far.







      bash signals trap bash-functions






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Feb 17 at 17:48







      Dominik Kummer

















      asked Feb 15 at 15:06









      Dominik KummerDominik Kummer

      788




      788




















          2 Answers
          2






          active

          oldest

          votes


















          2














          trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1


          Instead of using declare -i within the trap, do that beforehand, and just assign the new value in the trap:



          declare -i times=999
          trap 'times=3' USR1


          I think you could even use readonly times within the trap, since readonly in itself doesn't make the variable local.



          E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.



          #!/bin/bash
          trap 'readonly num=3' USR1
          sub()
          kill -USR1 $$
          echo "$num"


          declare -i num=999
          num=1
          echo "$num"
          sub
          echo "$num"
          num=1234


          Then again, if it's the global variable you want to modify, why not use declare -g?




          Is it possible to detach the kill -s USR1 $$ part completely from the current process, so that the signal comes from 'outside'?




          I don't think there's a difference between a signal sent by (the builtin) kill from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.






          share|improve this answer























          • you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.

            – Dominik Kummer
            Feb 17 at 17:42











          • @DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't use declare -g, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.

            – ilkkachu
            Feb 17 at 17:59











          • @ikkachu I wrote a custom Source function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with -g option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without -g option.

            – Dominik Kummer
            Feb 17 at 18:17



















          1














          #!/bin/bash

          setTraps ()
          trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1


          sendSignal ()
          kill -s USR1 "$$"


          setTraps
          sendSignal
          printf 'I want you to %s "hello"n' "$say"


          If you don't use declare at all, the trap will set the say variable to the string in global scope. The trap is still called within the scope of sendSignal scope though, but I don't think there's a way of changing that.






          share|improve this answer























          • even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.

            – Dominik Kummer
            Feb 16 at 12:59











          • regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach the kill -s USR1 "$$" completely from the process, so that the signal would come from "outside"?

            – Dominik Kummer
            Feb 16 at 13:23










          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
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f500894%2fhow-can-i-signal-a-trap-in-global-bash-scope-from-function%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









          2














          trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1


          Instead of using declare -i within the trap, do that beforehand, and just assign the new value in the trap:



          declare -i times=999
          trap 'times=3' USR1


          I think you could even use readonly times within the trap, since readonly in itself doesn't make the variable local.



          E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.



          #!/bin/bash
          trap 'readonly num=3' USR1
          sub()
          kill -USR1 $$
          echo "$num"


          declare -i num=999
          num=1
          echo "$num"
          sub
          echo "$num"
          num=1234


          Then again, if it's the global variable you want to modify, why not use declare -g?




          Is it possible to detach the kill -s USR1 $$ part completely from the current process, so that the signal comes from 'outside'?




          I don't think there's a difference between a signal sent by (the builtin) kill from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.






          share|improve this answer























          • you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.

            – Dominik Kummer
            Feb 17 at 17:42











          • @DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't use declare -g, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.

            – ilkkachu
            Feb 17 at 17:59











          • @ikkachu I wrote a custom Source function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with -g option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without -g option.

            – Dominik Kummer
            Feb 17 at 18:17
















          2














          trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1


          Instead of using declare -i within the trap, do that beforehand, and just assign the new value in the trap:



          declare -i times=999
          trap 'times=3' USR1


          I think you could even use readonly times within the trap, since readonly in itself doesn't make the variable local.



          E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.



          #!/bin/bash
          trap 'readonly num=3' USR1
          sub()
          kill -USR1 $$
          echo "$num"


          declare -i num=999
          num=1
          echo "$num"
          sub
          echo "$num"
          num=1234


          Then again, if it's the global variable you want to modify, why not use declare -g?




          Is it possible to detach the kill -s USR1 $$ part completely from the current process, so that the signal comes from 'outside'?




          I don't think there's a difference between a signal sent by (the builtin) kill from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.






          share|improve this answer























          • you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.

            – Dominik Kummer
            Feb 17 at 17:42











          • @DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't use declare -g, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.

            – ilkkachu
            Feb 17 at 17:59











          • @ikkachu I wrote a custom Source function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with -g option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without -g option.

            – Dominik Kummer
            Feb 17 at 18:17














          2












          2








          2







          trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1


          Instead of using declare -i within the trap, do that beforehand, and just assign the new value in the trap:



          declare -i times=999
          trap 'times=3' USR1


          I think you could even use readonly times within the trap, since readonly in itself doesn't make the variable local.



          E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.



          #!/bin/bash
          trap 'readonly num=3' USR1
          sub()
          kill -USR1 $$
          echo "$num"


          declare -i num=999
          num=1
          echo "$num"
          sub
          echo "$num"
          num=1234


          Then again, if it's the global variable you want to modify, why not use declare -g?




          Is it possible to detach the kill -s USR1 $$ part completely from the current process, so that the signal comes from 'outside'?




          I don't think there's a difference between a signal sent by (the builtin) kill from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.






          share|improve this answer













          trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1


          Instead of using declare -i within the trap, do that beforehand, and just assign the new value in the trap:



          declare -i times=999
          trap 'times=3' USR1


          I think you could even use readonly times within the trap, since readonly in itself doesn't make the variable local.



          E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.



          #!/bin/bash
          trap 'readonly num=3' USR1
          sub()
          kill -USR1 $$
          echo "$num"


          declare -i num=999
          num=1
          echo "$num"
          sub
          echo "$num"
          num=1234


          Then again, if it's the global variable you want to modify, why not use declare -g?




          Is it possible to detach the kill -s USR1 $$ part completely from the current process, so that the signal comes from 'outside'?




          I don't think there's a difference between a signal sent by (the builtin) kill from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 16 at 14:11









          ilkkachuilkkachu

          60.9k1098174




          60.9k1098174












          • you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.

            – Dominik Kummer
            Feb 17 at 17:42











          • @DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't use declare -g, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.

            – ilkkachu
            Feb 17 at 17:59











          • @ikkachu I wrote a custom Source function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with -g option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without -g option.

            – Dominik Kummer
            Feb 17 at 18:17


















          • you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.

            – Dominik Kummer
            Feb 17 at 17:42











          • @DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't use declare -g, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.

            – ilkkachu
            Feb 17 at 17:59











          • @ikkachu I wrote a custom Source function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with -g option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without -g option.

            – Dominik Kummer
            Feb 17 at 18:17

















          you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.

          – Dominik Kummer
          Feb 17 at 17:42





          you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.

          – Dominik Kummer
          Feb 17 at 17:42













          @DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't use declare -g, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.

          – ilkkachu
          Feb 17 at 17:59





          @DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't use declare -g, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.

          – ilkkachu
          Feb 17 at 17:59













          @ikkachu I wrote a custom Source function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with -g option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without -g option.

          – Dominik Kummer
          Feb 17 at 18:17






          @ikkachu I wrote a custom Source function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with -g option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without -g option.

          – Dominik Kummer
          Feb 17 at 18:17














          1














          #!/bin/bash

          setTraps ()
          trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1


          sendSignal ()
          kill -s USR1 "$$"


          setTraps
          sendSignal
          printf 'I want you to %s "hello"n' "$say"


          If you don't use declare at all, the trap will set the say variable to the string in global scope. The trap is still called within the scope of sendSignal scope though, but I don't think there's a way of changing that.






          share|improve this answer























          • even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.

            – Dominik Kummer
            Feb 16 at 12:59











          • regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach the kill -s USR1 "$$" completely from the process, so that the signal would come from "outside"?

            – Dominik Kummer
            Feb 16 at 13:23















          1














          #!/bin/bash

          setTraps ()
          trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1


          sendSignal ()
          kill -s USR1 "$$"


          setTraps
          sendSignal
          printf 'I want you to %s "hello"n' "$say"


          If you don't use declare at all, the trap will set the say variable to the string in global scope. The trap is still called within the scope of sendSignal scope though, but I don't think there's a way of changing that.






          share|improve this answer























          • even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.

            – Dominik Kummer
            Feb 16 at 12:59











          • regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach the kill -s USR1 "$$" completely from the process, so that the signal would come from "outside"?

            – Dominik Kummer
            Feb 16 at 13:23













          1












          1








          1







          #!/bin/bash

          setTraps ()
          trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1


          sendSignal ()
          kill -s USR1 "$$"


          setTraps
          sendSignal
          printf 'I want you to %s "hello"n' "$say"


          If you don't use declare at all, the trap will set the say variable to the string in global scope. The trap is still called within the scope of sendSignal scope though, but I don't think there's a way of changing that.






          share|improve this answer













          #!/bin/bash

          setTraps ()
          trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1


          sendSignal ()
          kill -s USR1 "$$"


          setTraps
          sendSignal
          printf 'I want you to %s "hello"n' "$say"


          If you don't use declare at all, the trap will set the say variable to the string in global scope. The trap is still called within the scope of sendSignal scope though, but I don't think there's a way of changing that.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 16 at 11:21









          KusalanandaKusalananda

          135k17255420




          135k17255420












          • even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.

            – Dominik Kummer
            Feb 16 at 12:59











          • regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach the kill -s USR1 "$$" completely from the process, so that the signal would come from "outside"?

            – Dominik Kummer
            Feb 16 at 13:23

















          • even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.

            – Dominik Kummer
            Feb 16 at 12:59











          • regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach the kill -s USR1 "$$" completely from the process, so that the signal would come from "outside"?

            – Dominik Kummer
            Feb 16 at 13:23
















          even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.

          – Dominik Kummer
          Feb 16 at 12:59





          even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.

          – Dominik Kummer
          Feb 16 at 12:59













          regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach the kill -s USR1 "$$" completely from the process, so that the signal would come from "outside"?

          – Dominik Kummer
          Feb 16 at 13:23





          regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach the kill -s USR1 "$$" completely from the process, so that the signal would come from "outside"?

          – Dominik Kummer
          Feb 16 at 13:23

















          draft saved

          draft discarded
















































          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%2f500894%2fhow-can-i-signal-a-trap-in-global-bash-scope-from-function%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

          How to check contact read email or not when send email to Individual?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay