Does bash support forking similar to C's fork()?












20















I have a script that I would like to fork at one point so two copies of the same script are running.



For example, I would like the following bash script to exist:



echo $$
do_fork()
echo $$


If this bash script truly existed, the expected output would be:



<ProcessA PID>
<ProcessB PID>
<ProcessA PID>


or



<ProcessA PID>
<ProcessA PID>
<ProcessB PID>


Is there something that I can put in place of "do_fork()" to get this kind of output, or to cause the bash script to do a C-like fork?










share|improve this question





























    20















    I have a script that I would like to fork at one point so two copies of the same script are running.



    For example, I would like the following bash script to exist:



    echo $$
    do_fork()
    echo $$


    If this bash script truly existed, the expected output would be:



    <ProcessA PID>
    <ProcessB PID>
    <ProcessA PID>


    or



    <ProcessA PID>
    <ProcessA PID>
    <ProcessB PID>


    Is there something that I can put in place of "do_fork()" to get this kind of output, or to cause the bash script to do a C-like fork?










    share|improve this question



























      20












      20








      20


      5






      I have a script that I would like to fork at one point so two copies of the same script are running.



      For example, I would like the following bash script to exist:



      echo $$
      do_fork()
      echo $$


      If this bash script truly existed, the expected output would be:



      <ProcessA PID>
      <ProcessB PID>
      <ProcessA PID>


      or



      <ProcessA PID>
      <ProcessA PID>
      <ProcessB PID>


      Is there something that I can put in place of "do_fork()" to get this kind of output, or to cause the bash script to do a C-like fork?










      share|improve this question
















      I have a script that I would like to fork at one point so two copies of the same script are running.



      For example, I would like the following bash script to exist:



      echo $$
      do_fork()
      echo $$


      If this bash script truly existed, the expected output would be:



      <ProcessA PID>
      <ProcessB PID>
      <ProcessA PID>


      or



      <ProcessA PID>
      <ProcessA PID>
      <ProcessB PID>


      Is there something that I can put in place of "do_fork()" to get this kind of output, or to cause the bash script to do a C-like fork?







      shell fork






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Feb 18 '11 at 0:27









      Gilles

      540k12810941609




      540k12810941609










      asked Feb 18 '11 at 0:06









      Cory KleinCory Klein

      5,512215984




      5,512215984






















          3 Answers
          3






          active

          oldest

          votes


















          18














          Yes. Forking is spelled &:



          echo child & echo parent


          What may be confusing you is that $$ is not the PID of the shell process, it's the PID of the original shell process. The point of making it this way is that $$ is a unique identifier for a particular instance of the shell script: it doesn't change during the script's execution, and it's different from $$ in any other concurrently running script. One way to get the shell process's actual PID is sh -c 'echo $PPID'.



          The control flow in the shell isn't the same as C. If in C you'd write



          first(); fork(); second(); third();


          then a shell equivalent is



          after_fork () { second; third; }
          first; after_fork & after_fork


          The simple shell form first; child & parent corresponds to the usual C idiom



          first(); if (fork()) parent(); else child();


          & and $$ exist and behave this way in every Bourne-style shell and in (t)csh. $PPID didn't exist in the orignal Bourne shell but is in POSIX (so it's in ash, bash, ksh, zsh, …).






          share|improve this answer





















          • 3





            But that's basically "fork + exec", not just fork.

            – mattdm
            Feb 18 '11 at 0:41











          • @mattdm: Uh? & is fork, there's no exec involved. Fork+exec is when you launch an external command.

            – Gilles
            Feb 18 '11 at 0:47











          • @mattdm: Ah, I think I see what Cory is getting at. There's no exec, but the two languages do have different control flow.

            – Gilles
            Feb 18 '11 at 0:55






          • 1





            @Gilles: The bash control operator & starts a subshell in which the given command is executed. Fork + exec. You can't just put & with no preceding command to execute.

            – mattdm
            Feb 18 '11 at 0:58






          • 5





            Well, if "Forking is spelled &" were a true statement, you could put & on a line by itself. But you can't. It doesn't mean "fork here". It means "execute the preceding command in the background in a subshell".

            – mattdm
            Feb 18 '11 at 1:36



















          5














          There's no native bash (or, to my knowledge, any other typical *nix shell) way of doing this. There's a lot of ways to spawn forked processes that do something else asynchronously, but I don't think there's anything that follows the exact semantics of the fork() system call.



          The typical approach would be to have your top-level script spawn off helpers that do just the work you want split out. If you do $0 $@ & or whatever, you'll start at the beginning again and need to figure that out somehow.



          I'm actually starting to think of several clever ways in which one might do just that....



          But, before my brain gets too carried away with that, I think a pretty good rule is: if you're trying to write something in shell and it's getting full of clever tricks and you're wishing for more language features, time to switch to a real programming language.






          share|improve this answer



















          • 1





            Although your point is well taken- bash's syntax is arguably difficult and it's missing the more elegant data structures and features of Perl or Python, bash is as real as it gets- in its domain. It is a domain-specific language, and I would argue even better (more succinct, simpler) than eg Python in many instances. Can you administer a roomful of systems and not know Python? Yes. Can you do that and not know a lick of bash [programming]? I wouldn't want to try. After 30 years of shell programming I tell you it's as real as it gets. And yes, I speak Python. But don't confuse the youngsters.

            – Mike S
            May 10 '16 at 13:21






          • 1





            That said, technically I like this answer more. To say that "&" is the answer to the user's question, "fork at one point so two copies of the same script are running" is to my mind confusing. What "&" does, according to the bash manual, is "...executes the [given] command in the background in a subshell." It must terminate a command, and it does involve a fork (technically, in Linux, a clone() ), but at that point two copies of the same script are not running.

            – Mike S
            May 10 '16 at 13:39



















          5














          Yes, it's called subshells. Shell code inside parenthesis is run as a subshell (fork). However the first shell normally waits for the child to complete. You can make it asynchronous using the & terminator. See it in in action with something like this:



          #!/bin/bash

          (sleep 2; echo "subsh 1")&
          echo "topsh"


          $ bash subsh.sh






          share|improve this answer



















          • 4





            The parentheses create a subshell, but that's fork+wait. & is fork alone. If you want to execute more than one pipeline in the child process, it's enough to use braces (which perform grouping without creating a child process): { sleep 2; echo child; } &

            – Gilles
            Feb 18 '11 at 8:31











          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%2f7608%2fdoes-bash-support-forking-similar-to-cs-fork%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          3 Answers
          3






          active

          oldest

          votes








          3 Answers
          3






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          18














          Yes. Forking is spelled &:



          echo child & echo parent


          What may be confusing you is that $$ is not the PID of the shell process, it's the PID of the original shell process. The point of making it this way is that $$ is a unique identifier for a particular instance of the shell script: it doesn't change during the script's execution, and it's different from $$ in any other concurrently running script. One way to get the shell process's actual PID is sh -c 'echo $PPID'.



          The control flow in the shell isn't the same as C. If in C you'd write



          first(); fork(); second(); third();


          then a shell equivalent is



          after_fork () { second; third; }
          first; after_fork & after_fork


          The simple shell form first; child & parent corresponds to the usual C idiom



          first(); if (fork()) parent(); else child();


          & and $$ exist and behave this way in every Bourne-style shell and in (t)csh. $PPID didn't exist in the orignal Bourne shell but is in POSIX (so it's in ash, bash, ksh, zsh, …).






          share|improve this answer





















          • 3





            But that's basically "fork + exec", not just fork.

            – mattdm
            Feb 18 '11 at 0:41











          • @mattdm: Uh? & is fork, there's no exec involved. Fork+exec is when you launch an external command.

            – Gilles
            Feb 18 '11 at 0:47











          • @mattdm: Ah, I think I see what Cory is getting at. There's no exec, but the two languages do have different control flow.

            – Gilles
            Feb 18 '11 at 0:55






          • 1





            @Gilles: The bash control operator & starts a subshell in which the given command is executed. Fork + exec. You can't just put & with no preceding command to execute.

            – mattdm
            Feb 18 '11 at 0:58






          • 5





            Well, if "Forking is spelled &" were a true statement, you could put & on a line by itself. But you can't. It doesn't mean "fork here". It means "execute the preceding command in the background in a subshell".

            – mattdm
            Feb 18 '11 at 1:36
















          18














          Yes. Forking is spelled &:



          echo child & echo parent


          What may be confusing you is that $$ is not the PID of the shell process, it's the PID of the original shell process. The point of making it this way is that $$ is a unique identifier for a particular instance of the shell script: it doesn't change during the script's execution, and it's different from $$ in any other concurrently running script. One way to get the shell process's actual PID is sh -c 'echo $PPID'.



          The control flow in the shell isn't the same as C. If in C you'd write



          first(); fork(); second(); third();


          then a shell equivalent is



          after_fork () { second; third; }
          first; after_fork & after_fork


          The simple shell form first; child & parent corresponds to the usual C idiom



          first(); if (fork()) parent(); else child();


          & and $$ exist and behave this way in every Bourne-style shell and in (t)csh. $PPID didn't exist in the orignal Bourne shell but is in POSIX (so it's in ash, bash, ksh, zsh, …).






          share|improve this answer





















          • 3





            But that's basically "fork + exec", not just fork.

            – mattdm
            Feb 18 '11 at 0:41











          • @mattdm: Uh? & is fork, there's no exec involved. Fork+exec is when you launch an external command.

            – Gilles
            Feb 18 '11 at 0:47











          • @mattdm: Ah, I think I see what Cory is getting at. There's no exec, but the two languages do have different control flow.

            – Gilles
            Feb 18 '11 at 0:55






          • 1





            @Gilles: The bash control operator & starts a subshell in which the given command is executed. Fork + exec. You can't just put & with no preceding command to execute.

            – mattdm
            Feb 18 '11 at 0:58






          • 5





            Well, if "Forking is spelled &" were a true statement, you could put & on a line by itself. But you can't. It doesn't mean "fork here". It means "execute the preceding command in the background in a subshell".

            – mattdm
            Feb 18 '11 at 1:36














          18












          18








          18







          Yes. Forking is spelled &:



          echo child & echo parent


          What may be confusing you is that $$ is not the PID of the shell process, it's the PID of the original shell process. The point of making it this way is that $$ is a unique identifier for a particular instance of the shell script: it doesn't change during the script's execution, and it's different from $$ in any other concurrently running script. One way to get the shell process's actual PID is sh -c 'echo $PPID'.



          The control flow in the shell isn't the same as C. If in C you'd write



          first(); fork(); second(); third();


          then a shell equivalent is



          after_fork () { second; third; }
          first; after_fork & after_fork


          The simple shell form first; child & parent corresponds to the usual C idiom



          first(); if (fork()) parent(); else child();


          & and $$ exist and behave this way in every Bourne-style shell and in (t)csh. $PPID didn't exist in the orignal Bourne shell but is in POSIX (so it's in ash, bash, ksh, zsh, …).






          share|improve this answer















          Yes. Forking is spelled &:



          echo child & echo parent


          What may be confusing you is that $$ is not the PID of the shell process, it's the PID of the original shell process. The point of making it this way is that $$ is a unique identifier for a particular instance of the shell script: it doesn't change during the script's execution, and it's different from $$ in any other concurrently running script. One way to get the shell process's actual PID is sh -c 'echo $PPID'.



          The control flow in the shell isn't the same as C. If in C you'd write



          first(); fork(); second(); third();


          then a shell equivalent is



          after_fork () { second; third; }
          first; after_fork & after_fork


          The simple shell form first; child & parent corresponds to the usual C idiom



          first(); if (fork()) parent(); else child();


          & and $$ exist and behave this way in every Bourne-style shell and in (t)csh. $PPID didn't exist in the orignal Bourne shell but is in POSIX (so it's in ash, bash, ksh, zsh, …).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 24 '18 at 7:37

























          answered Feb 18 '11 at 0:27









          GillesGilles

          540k12810941609




          540k12810941609








          • 3





            But that's basically "fork + exec", not just fork.

            – mattdm
            Feb 18 '11 at 0:41











          • @mattdm: Uh? & is fork, there's no exec involved. Fork+exec is when you launch an external command.

            – Gilles
            Feb 18 '11 at 0:47











          • @mattdm: Ah, I think I see what Cory is getting at. There's no exec, but the two languages do have different control flow.

            – Gilles
            Feb 18 '11 at 0:55






          • 1





            @Gilles: The bash control operator & starts a subshell in which the given command is executed. Fork + exec. You can't just put & with no preceding command to execute.

            – mattdm
            Feb 18 '11 at 0:58






          • 5





            Well, if "Forking is spelled &" were a true statement, you could put & on a line by itself. But you can't. It doesn't mean "fork here". It means "execute the preceding command in the background in a subshell".

            – mattdm
            Feb 18 '11 at 1:36














          • 3





            But that's basically "fork + exec", not just fork.

            – mattdm
            Feb 18 '11 at 0:41











          • @mattdm: Uh? & is fork, there's no exec involved. Fork+exec is when you launch an external command.

            – Gilles
            Feb 18 '11 at 0:47











          • @mattdm: Ah, I think I see what Cory is getting at. There's no exec, but the two languages do have different control flow.

            – Gilles
            Feb 18 '11 at 0:55






          • 1





            @Gilles: The bash control operator & starts a subshell in which the given command is executed. Fork + exec. You can't just put & with no preceding command to execute.

            – mattdm
            Feb 18 '11 at 0:58






          • 5





            Well, if "Forking is spelled &" were a true statement, you could put & on a line by itself. But you can't. It doesn't mean "fork here". It means "execute the preceding command in the background in a subshell".

            – mattdm
            Feb 18 '11 at 1:36








          3




          3





          But that's basically "fork + exec", not just fork.

          – mattdm
          Feb 18 '11 at 0:41





          But that's basically "fork + exec", not just fork.

          – mattdm
          Feb 18 '11 at 0:41













          @mattdm: Uh? & is fork, there's no exec involved. Fork+exec is when you launch an external command.

          – Gilles
          Feb 18 '11 at 0:47





          @mattdm: Uh? & is fork, there's no exec involved. Fork+exec is when you launch an external command.

          – Gilles
          Feb 18 '11 at 0:47













          @mattdm: Ah, I think I see what Cory is getting at. There's no exec, but the two languages do have different control flow.

          – Gilles
          Feb 18 '11 at 0:55





          @mattdm: Ah, I think I see what Cory is getting at. There's no exec, but the two languages do have different control flow.

          – Gilles
          Feb 18 '11 at 0:55




          1




          1





          @Gilles: The bash control operator & starts a subshell in which the given command is executed. Fork + exec. You can't just put & with no preceding command to execute.

          – mattdm
          Feb 18 '11 at 0:58





          @Gilles: The bash control operator & starts a subshell in which the given command is executed. Fork + exec. You can't just put & with no preceding command to execute.

          – mattdm
          Feb 18 '11 at 0:58




          5




          5





          Well, if "Forking is spelled &" were a true statement, you could put & on a line by itself. But you can't. It doesn't mean "fork here". It means "execute the preceding command in the background in a subshell".

          – mattdm
          Feb 18 '11 at 1:36





          Well, if "Forking is spelled &" were a true statement, you could put & on a line by itself. But you can't. It doesn't mean "fork here". It means "execute the preceding command in the background in a subshell".

          – mattdm
          Feb 18 '11 at 1:36













          5














          There's no native bash (or, to my knowledge, any other typical *nix shell) way of doing this. There's a lot of ways to spawn forked processes that do something else asynchronously, but I don't think there's anything that follows the exact semantics of the fork() system call.



          The typical approach would be to have your top-level script spawn off helpers that do just the work you want split out. If you do $0 $@ & or whatever, you'll start at the beginning again and need to figure that out somehow.



          I'm actually starting to think of several clever ways in which one might do just that....



          But, before my brain gets too carried away with that, I think a pretty good rule is: if you're trying to write something in shell and it's getting full of clever tricks and you're wishing for more language features, time to switch to a real programming language.






          share|improve this answer



















          • 1





            Although your point is well taken- bash's syntax is arguably difficult and it's missing the more elegant data structures and features of Perl or Python, bash is as real as it gets- in its domain. It is a domain-specific language, and I would argue even better (more succinct, simpler) than eg Python in many instances. Can you administer a roomful of systems and not know Python? Yes. Can you do that and not know a lick of bash [programming]? I wouldn't want to try. After 30 years of shell programming I tell you it's as real as it gets. And yes, I speak Python. But don't confuse the youngsters.

            – Mike S
            May 10 '16 at 13:21






          • 1





            That said, technically I like this answer more. To say that "&" is the answer to the user's question, "fork at one point so two copies of the same script are running" is to my mind confusing. What "&" does, according to the bash manual, is "...executes the [given] command in the background in a subshell." It must terminate a command, and it does involve a fork (technically, in Linux, a clone() ), but at that point two copies of the same script are not running.

            – Mike S
            May 10 '16 at 13:39
















          5














          There's no native bash (or, to my knowledge, any other typical *nix shell) way of doing this. There's a lot of ways to spawn forked processes that do something else asynchronously, but I don't think there's anything that follows the exact semantics of the fork() system call.



          The typical approach would be to have your top-level script spawn off helpers that do just the work you want split out. If you do $0 $@ & or whatever, you'll start at the beginning again and need to figure that out somehow.



          I'm actually starting to think of several clever ways in which one might do just that....



          But, before my brain gets too carried away with that, I think a pretty good rule is: if you're trying to write something in shell and it's getting full of clever tricks and you're wishing for more language features, time to switch to a real programming language.






          share|improve this answer



















          • 1





            Although your point is well taken- bash's syntax is arguably difficult and it's missing the more elegant data structures and features of Perl or Python, bash is as real as it gets- in its domain. It is a domain-specific language, and I would argue even better (more succinct, simpler) than eg Python in many instances. Can you administer a roomful of systems and not know Python? Yes. Can you do that and not know a lick of bash [programming]? I wouldn't want to try. After 30 years of shell programming I tell you it's as real as it gets. And yes, I speak Python. But don't confuse the youngsters.

            – Mike S
            May 10 '16 at 13:21






          • 1





            That said, technically I like this answer more. To say that "&" is the answer to the user's question, "fork at one point so two copies of the same script are running" is to my mind confusing. What "&" does, according to the bash manual, is "...executes the [given] command in the background in a subshell." It must terminate a command, and it does involve a fork (technically, in Linux, a clone() ), but at that point two copies of the same script are not running.

            – Mike S
            May 10 '16 at 13:39














          5












          5








          5







          There's no native bash (or, to my knowledge, any other typical *nix shell) way of doing this. There's a lot of ways to spawn forked processes that do something else asynchronously, but I don't think there's anything that follows the exact semantics of the fork() system call.



          The typical approach would be to have your top-level script spawn off helpers that do just the work you want split out. If you do $0 $@ & or whatever, you'll start at the beginning again and need to figure that out somehow.



          I'm actually starting to think of several clever ways in which one might do just that....



          But, before my brain gets too carried away with that, I think a pretty good rule is: if you're trying to write something in shell and it's getting full of clever tricks and you're wishing for more language features, time to switch to a real programming language.






          share|improve this answer













          There's no native bash (or, to my knowledge, any other typical *nix shell) way of doing this. There's a lot of ways to spawn forked processes that do something else asynchronously, but I don't think there's anything that follows the exact semantics of the fork() system call.



          The typical approach would be to have your top-level script spawn off helpers that do just the work you want split out. If you do $0 $@ & or whatever, you'll start at the beginning again and need to figure that out somehow.



          I'm actually starting to think of several clever ways in which one might do just that....



          But, before my brain gets too carried away with that, I think a pretty good rule is: if you're trying to write something in shell and it's getting full of clever tricks and you're wishing for more language features, time to switch to a real programming language.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 18 '11 at 0:36









          mattdmmattdm

          28.8k1372116




          28.8k1372116








          • 1





            Although your point is well taken- bash's syntax is arguably difficult and it's missing the more elegant data structures and features of Perl or Python, bash is as real as it gets- in its domain. It is a domain-specific language, and I would argue even better (more succinct, simpler) than eg Python in many instances. Can you administer a roomful of systems and not know Python? Yes. Can you do that and not know a lick of bash [programming]? I wouldn't want to try. After 30 years of shell programming I tell you it's as real as it gets. And yes, I speak Python. But don't confuse the youngsters.

            – Mike S
            May 10 '16 at 13:21






          • 1





            That said, technically I like this answer more. To say that "&" is the answer to the user's question, "fork at one point so two copies of the same script are running" is to my mind confusing. What "&" does, according to the bash manual, is "...executes the [given] command in the background in a subshell." It must terminate a command, and it does involve a fork (technically, in Linux, a clone() ), but at that point two copies of the same script are not running.

            – Mike S
            May 10 '16 at 13:39














          • 1





            Although your point is well taken- bash's syntax is arguably difficult and it's missing the more elegant data structures and features of Perl or Python, bash is as real as it gets- in its domain. It is a domain-specific language, and I would argue even better (more succinct, simpler) than eg Python in many instances. Can you administer a roomful of systems and not know Python? Yes. Can you do that and not know a lick of bash [programming]? I wouldn't want to try. After 30 years of shell programming I tell you it's as real as it gets. And yes, I speak Python. But don't confuse the youngsters.

            – Mike S
            May 10 '16 at 13:21






          • 1





            That said, technically I like this answer more. To say that "&" is the answer to the user's question, "fork at one point so two copies of the same script are running" is to my mind confusing. What "&" does, according to the bash manual, is "...executes the [given] command in the background in a subshell." It must terminate a command, and it does involve a fork (technically, in Linux, a clone() ), but at that point two copies of the same script are not running.

            – Mike S
            May 10 '16 at 13:39








          1




          1





          Although your point is well taken- bash's syntax is arguably difficult and it's missing the more elegant data structures and features of Perl or Python, bash is as real as it gets- in its domain. It is a domain-specific language, and I would argue even better (more succinct, simpler) than eg Python in many instances. Can you administer a roomful of systems and not know Python? Yes. Can you do that and not know a lick of bash [programming]? I wouldn't want to try. After 30 years of shell programming I tell you it's as real as it gets. And yes, I speak Python. But don't confuse the youngsters.

          – Mike S
          May 10 '16 at 13:21





          Although your point is well taken- bash's syntax is arguably difficult and it's missing the more elegant data structures and features of Perl or Python, bash is as real as it gets- in its domain. It is a domain-specific language, and I would argue even better (more succinct, simpler) than eg Python in many instances. Can you administer a roomful of systems and not know Python? Yes. Can you do that and not know a lick of bash [programming]? I wouldn't want to try. After 30 years of shell programming I tell you it's as real as it gets. And yes, I speak Python. But don't confuse the youngsters.

          – Mike S
          May 10 '16 at 13:21




          1




          1





          That said, technically I like this answer more. To say that "&" is the answer to the user's question, "fork at one point so two copies of the same script are running" is to my mind confusing. What "&" does, according to the bash manual, is "...executes the [given] command in the background in a subshell." It must terminate a command, and it does involve a fork (technically, in Linux, a clone() ), but at that point two copies of the same script are not running.

          – Mike S
          May 10 '16 at 13:39





          That said, technically I like this answer more. To say that "&" is the answer to the user's question, "fork at one point so two copies of the same script are running" is to my mind confusing. What "&" does, according to the bash manual, is "...executes the [given] command in the background in a subshell." It must terminate a command, and it does involve a fork (technically, in Linux, a clone() ), but at that point two copies of the same script are not running.

          – Mike S
          May 10 '16 at 13:39











          5














          Yes, it's called subshells. Shell code inside parenthesis is run as a subshell (fork). However the first shell normally waits for the child to complete. You can make it asynchronous using the & terminator. See it in in action with something like this:



          #!/bin/bash

          (sleep 2; echo "subsh 1")&
          echo "topsh"


          $ bash subsh.sh






          share|improve this answer



















          • 4





            The parentheses create a subshell, but that's fork+wait. & is fork alone. If you want to execute more than one pipeline in the child process, it's enough to use braces (which perform grouping without creating a child process): { sleep 2; echo child; } &

            – Gilles
            Feb 18 '11 at 8:31
















          5














          Yes, it's called subshells. Shell code inside parenthesis is run as a subshell (fork). However the first shell normally waits for the child to complete. You can make it asynchronous using the & terminator. See it in in action with something like this:



          #!/bin/bash

          (sleep 2; echo "subsh 1")&
          echo "topsh"


          $ bash subsh.sh






          share|improve this answer



















          • 4





            The parentheses create a subshell, but that's fork+wait. & is fork alone. If you want to execute more than one pipeline in the child process, it's enough to use braces (which perform grouping without creating a child process): { sleep 2; echo child; } &

            – Gilles
            Feb 18 '11 at 8:31














          5












          5








          5







          Yes, it's called subshells. Shell code inside parenthesis is run as a subshell (fork). However the first shell normally waits for the child to complete. You can make it asynchronous using the & terminator. See it in in action with something like this:



          #!/bin/bash

          (sleep 2; echo "subsh 1")&
          echo "topsh"


          $ bash subsh.sh






          share|improve this answer













          Yes, it's called subshells. Shell code inside parenthesis is run as a subshell (fork). However the first shell normally waits for the child to complete. You can make it asynchronous using the & terminator. See it in in action with something like this:



          #!/bin/bash

          (sleep 2; echo "subsh 1")&
          echo "topsh"


          $ bash subsh.sh







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 18 '11 at 5:29









          KeithKeith

          6,3781924




          6,3781924








          • 4





            The parentheses create a subshell, but that's fork+wait. & is fork alone. If you want to execute more than one pipeline in the child process, it's enough to use braces (which perform grouping without creating a child process): { sleep 2; echo child; } &

            – Gilles
            Feb 18 '11 at 8:31














          • 4





            The parentheses create a subshell, but that's fork+wait. & is fork alone. If you want to execute more than one pipeline in the child process, it's enough to use braces (which perform grouping without creating a child process): { sleep 2; echo child; } &

            – Gilles
            Feb 18 '11 at 8:31








          4




          4





          The parentheses create a subshell, but that's fork+wait. & is fork alone. If you want to execute more than one pipeline in the child process, it's enough to use braces (which perform grouping without creating a child process): { sleep 2; echo child; } &

          – Gilles
          Feb 18 '11 at 8:31





          The parentheses create a subshell, but that's fork+wait. & is fork alone. If you want to execute more than one pipeline in the child process, it's enough to use braces (which perform grouping without creating a child process): { sleep 2; echo child; } &

          – Gilles
          Feb 18 '11 at 8:31


















          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%2f7608%2fdoes-bash-support-forking-similar-to-cs-fork%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

          Histoire des bourses de valeurs

          Why is there Russian traffic in my log files?

          Rename multiple files to decrement number in file name?