When receiving SIGINT, does bash also quit other commands, besides loops (for or while)?

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











up vote
1
down vote

favorite












From bash manual




When Bash receives a SIGINT, it breaks out of any executing loops.




When receiving SIGINT, does bash also quit other commands, besides loops (for or while)? Thanks.







share|improve this question























    up vote
    1
    down vote

    favorite












    From bash manual




    When Bash receives a SIGINT, it breaks out of any executing loops.




    When receiving SIGINT, does bash also quit other commands, besides loops (for or while)? Thanks.







    share|improve this question





















      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      From bash manual




      When Bash receives a SIGINT, it breaks out of any executing loops.




      When receiving SIGINT, does bash also quit other commands, besides loops (for or while)? Thanks.







      share|improve this question











      From bash manual




      When Bash receives a SIGINT, it breaks out of any executing loops.




      When receiving SIGINT, does bash also quit other commands, besides loops (for or while)? Thanks.









      share|improve this question










      share|improve this question




      share|improve this question









      asked May 28 at 1:56









      Tim

      22.6k61222401




      22.6k61222401




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          2
          down vote



          accepted










          Quoting the bash manual:




          When bash is interactive, in the absence of any traps, it ignores
          SIGTERM (so that kill 0 does not kill an interactive shell), and
          SIGINT is caught and handled (so that the wait builtin is interruptible).




          Yes, bash quits builtins when it receives SIGINT. You can verify that with wait or read (read from a large file with no newlines will give you time to press CtrlC). wait in particular needs to deal with SIGINT correctly, as per POSIX (along with all other signals it can come across).






          share|improve this answer























          • Thanks. Besides loop and builtins, does bash quit anything else?
            – Tim
            May 28 at 11:39










          • What else could it quit?
            – Stephen Kitt
            May 28 at 13:07











          • like other control flow contructs such as "if" and external commands? Why are they not mentioned?
            – Tim
            May 28 at 13:14











          • External commands deal with SIGINT themselves (the shell is informed if an external command was killed by a signal, but it deals with that by interpreting the information given by wait(2) or waitpid(2), not by installing a signal handler). if etc. run at a point in time, so there’s not much point in making them interruptible.
            – Stephen Kitt
            May 28 at 13:22










          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',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          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%2f446378%2fwhen-receiving-sigint-does-bash-also-quit-other-commands-besides-loops-for-or%23new-answer', 'question_page');

          );

          Post as a guest






























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          2
          down vote



          accepted










          Quoting the bash manual:




          When bash is interactive, in the absence of any traps, it ignores
          SIGTERM (so that kill 0 does not kill an interactive shell), and
          SIGINT is caught and handled (so that the wait builtin is interruptible).




          Yes, bash quits builtins when it receives SIGINT. You can verify that with wait or read (read from a large file with no newlines will give you time to press CtrlC). wait in particular needs to deal with SIGINT correctly, as per POSIX (along with all other signals it can come across).






          share|improve this answer























          • Thanks. Besides loop and builtins, does bash quit anything else?
            – Tim
            May 28 at 11:39










          • What else could it quit?
            – Stephen Kitt
            May 28 at 13:07











          • like other control flow contructs such as "if" and external commands? Why are they not mentioned?
            – Tim
            May 28 at 13:14











          • External commands deal with SIGINT themselves (the shell is informed if an external command was killed by a signal, but it deals with that by interpreting the information given by wait(2) or waitpid(2), not by installing a signal handler). if etc. run at a point in time, so there’s not much point in making them interruptible.
            – Stephen Kitt
            May 28 at 13:22














          up vote
          2
          down vote



          accepted










          Quoting the bash manual:




          When bash is interactive, in the absence of any traps, it ignores
          SIGTERM (so that kill 0 does not kill an interactive shell), and
          SIGINT is caught and handled (so that the wait builtin is interruptible).




          Yes, bash quits builtins when it receives SIGINT. You can verify that with wait or read (read from a large file with no newlines will give you time to press CtrlC). wait in particular needs to deal with SIGINT correctly, as per POSIX (along with all other signals it can come across).






          share|improve this answer























          • Thanks. Besides loop and builtins, does bash quit anything else?
            – Tim
            May 28 at 11:39










          • What else could it quit?
            – Stephen Kitt
            May 28 at 13:07











          • like other control flow contructs such as "if" and external commands? Why are they not mentioned?
            – Tim
            May 28 at 13:14











          • External commands deal with SIGINT themselves (the shell is informed if an external command was killed by a signal, but it deals with that by interpreting the information given by wait(2) or waitpid(2), not by installing a signal handler). if etc. run at a point in time, so there’s not much point in making them interruptible.
            – Stephen Kitt
            May 28 at 13:22












          up vote
          2
          down vote



          accepted







          up vote
          2
          down vote



          accepted






          Quoting the bash manual:




          When bash is interactive, in the absence of any traps, it ignores
          SIGTERM (so that kill 0 does not kill an interactive shell), and
          SIGINT is caught and handled (so that the wait builtin is interruptible).




          Yes, bash quits builtins when it receives SIGINT. You can verify that with wait or read (read from a large file with no newlines will give you time to press CtrlC). wait in particular needs to deal with SIGINT correctly, as per POSIX (along with all other signals it can come across).






          share|improve this answer















          Quoting the bash manual:




          When bash is interactive, in the absence of any traps, it ignores
          SIGTERM (so that kill 0 does not kill an interactive shell), and
          SIGINT is caught and handled (so that the wait builtin is interruptible).




          Yes, bash quits builtins when it receives SIGINT. You can verify that with wait or read (read from a large file with no newlines will give you time to press CtrlC). wait in particular needs to deal with SIGINT correctly, as per POSIX (along with all other signals it can come across).







          share|improve this answer















          share|improve this answer



          share|improve this answer








          edited May 28 at 13:09


























          answered May 28 at 5:24









          Stephen Kitt

          140k22302363




          140k22302363











          • Thanks. Besides loop and builtins, does bash quit anything else?
            – Tim
            May 28 at 11:39










          • What else could it quit?
            – Stephen Kitt
            May 28 at 13:07











          • like other control flow contructs such as "if" and external commands? Why are they not mentioned?
            – Tim
            May 28 at 13:14











          • External commands deal with SIGINT themselves (the shell is informed if an external command was killed by a signal, but it deals with that by interpreting the information given by wait(2) or waitpid(2), not by installing a signal handler). if etc. run at a point in time, so there’s not much point in making them interruptible.
            – Stephen Kitt
            May 28 at 13:22
















          • Thanks. Besides loop and builtins, does bash quit anything else?
            – Tim
            May 28 at 11:39










          • What else could it quit?
            – Stephen Kitt
            May 28 at 13:07











          • like other control flow contructs such as "if" and external commands? Why are they not mentioned?
            – Tim
            May 28 at 13:14











          • External commands deal with SIGINT themselves (the shell is informed if an external command was killed by a signal, but it deals with that by interpreting the information given by wait(2) or waitpid(2), not by installing a signal handler). if etc. run at a point in time, so there’s not much point in making them interruptible.
            – Stephen Kitt
            May 28 at 13:22















          Thanks. Besides loop and builtins, does bash quit anything else?
          – Tim
          May 28 at 11:39




          Thanks. Besides loop and builtins, does bash quit anything else?
          – Tim
          May 28 at 11:39












          What else could it quit?
          – Stephen Kitt
          May 28 at 13:07





          What else could it quit?
          – Stephen Kitt
          May 28 at 13:07













          like other control flow contructs such as "if" and external commands? Why are they not mentioned?
          – Tim
          May 28 at 13:14





          like other control flow contructs such as "if" and external commands? Why are they not mentioned?
          – Tim
          May 28 at 13:14













          External commands deal with SIGINT themselves (the shell is informed if an external command was killed by a signal, but it deals with that by interpreting the information given by wait(2) or waitpid(2), not by installing a signal handler). if etc. run at a point in time, so there’s not much point in making them interruptible.
          – Stephen Kitt
          May 28 at 13:22




          External commands deal with SIGINT themselves (the shell is informed if an external command was killed by a signal, but it deals with that by interpreting the information given by wait(2) or waitpid(2), not by installing a signal handler). if etc. run at a point in time, so there’s not much point in making them interruptible.
          – Stephen Kitt
          May 28 at 13:22












           

          draft saved


          draft discarded


























           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f446378%2fwhen-receiving-sigint-does-bash-also-quit-other-commands-besides-loops-for-or%23new-answer', 'question_page');

          );

          Post as a guest













































































          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