What is the meaning of & at the end of a command?












9















I have a startup script line:



pyprogramm >> /dev/null  2>&1 &


Meanings:



>> /dev/null - redirect stdout to null device
2>&1 - redirect stderr to stdout (that is redirected to null device)


but what does the very last & mean?










share|improve this question





























    9















    I have a startup script line:



    pyprogramm >> /dev/null  2>&1 &


    Meanings:



    >> /dev/null - redirect stdout to null device
    2>&1 - redirect stderr to stdout (that is redirected to null device)


    but what does the very last & mean?










    share|improve this question



























      9












      9








      9


      3






      I have a startup script line:



      pyprogramm >> /dev/null  2>&1 &


      Meanings:



      >> /dev/null - redirect stdout to null device
      2>&1 - redirect stderr to stdout (that is redirected to null device)


      but what does the very last & mean?










      share|improve this question
















      I have a startup script line:



      pyprogramm >> /dev/null  2>&1 &


      Meanings:



      >> /dev/null - redirect stdout to null device
      2>&1 - redirect stderr to stdout (that is redirected to null device)


      but what does the very last & mean?







      bash scripts stdout job-control






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 6 at 8:45









      Zanna

      50.5k13133241




      50.5k13133241










      asked Jan 5 at 8:40









      vicovico

      1,16672645




      1,16672645






















          3 Answers
          3






          active

          oldest

          votes


















          13














          What is the & terminator ?



          The trailing & operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:




          Asynchronous Lists



          If a command is terminated by the control operator
          ( '&' ), the shell shall execute the command
          asynchronously in a subshell. This means that the shell shall not wait
          for the command to finish before executing the next command.



          The format for running a command in the background is:



          command1 & [command2 & ... ]




          The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.



          From the definition you can see that & also serves as command terminator for lists of commands, much like ; does. In your specific example, pyprogramm >> /dev/null 2>&1 & there is only one command in the list.



          Sequential ; lists vs asynchronous & lists



          More generally,



          echo Hello ; echo World ;


          and



          echo Hello & echo World &


          are two examples of lists terminated by the ; and & operators. One difference is that & terminated list will have input connected to /dev/null if job control is disabled:




          If job control is disabled (see set, -m), the standard input for an
          asynchronous list, before any explicit redirections are performed,
          shall be considered to be assigned to a file that has the same
          properties as /dev/null. This shall not happen if job control is
          enabled. In all cases, explicit redirection of standard input shall
          override this activity.




          In sequential list, however, each command still has stdin connected to terminal if there are no explicit redirections.



          Note also, that from the definition we mentioned earlier, & executes commands in subshell. By contrast, the ; terminated list is executed in current shell. There's also difference in exit statuses. For & the standard says:




          The exit status of an asynchronous list shall be zero.




          This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 & running in background should have some way of indicating if it failed or not, however judging that you use 2>&1 you are hiding error output by redirecting, and you probably assume the script should not fail.



          By contrast, ; exit status is defined as:




          The exit status of a sequential list shall be the exit status of the
          last command in the list.




          Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.





          Side notes and additional reading




          • The fact that this is POSIX definition means that all Bourne-like shells, meaning bash, dash, and ksh must support it.


          • & in redirection is different from & as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?



          • In bash there is also |& operator ( note no space between pipe and ampersand ). From bash manual:




            If |& is used, command's standard error, in addition to its standard
            output, is connected to command2's standard input through the pipe;
            it is shorthand for 2>&1 |. This implicit redirection of the
            standard error to the standard output is performed after any
            redirections specified by the command.









          share|improve this answer





















          • 2





            What you say about & hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from /dev/null or equivalent.

            – kasperd
            Jan 5 at 17:29











          • @kasperd That's an oopsie. Fixed. Thanks !

            – Sergiy Kolodyazhnyy
            Jan 5 at 21:15











          • I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.

            – kasperd
            Jan 5 at 21:33











          • @kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)

            – Sergiy Kolodyazhnyy
            Jan 5 at 21:37



















          2














          It means run the command in the background. The calling script continues rather than blocking until the called command completes.






          share|improve this answer































            0














            & this returns control of the script to the operating system but sent the response to the background not as nohup that directly sends the entire execution






            share|improve this answer























              Your Answer








              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "89"
              };
              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: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              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%2faskubuntu.com%2fquestions%2f1107124%2fwhat-is-the-meaning-of-at-the-end-of-a-command%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









              13














              What is the & terminator ?



              The trailing & operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:




              Asynchronous Lists



              If a command is terminated by the control operator
              ( '&' ), the shell shall execute the command
              asynchronously in a subshell. This means that the shell shall not wait
              for the command to finish before executing the next command.



              The format for running a command in the background is:



              command1 & [command2 & ... ]




              The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.



              From the definition you can see that & also serves as command terminator for lists of commands, much like ; does. In your specific example, pyprogramm >> /dev/null 2>&1 & there is only one command in the list.



              Sequential ; lists vs asynchronous & lists



              More generally,



              echo Hello ; echo World ;


              and



              echo Hello & echo World &


              are two examples of lists terminated by the ; and & operators. One difference is that & terminated list will have input connected to /dev/null if job control is disabled:




              If job control is disabled (see set, -m), the standard input for an
              asynchronous list, before any explicit redirections are performed,
              shall be considered to be assigned to a file that has the same
              properties as /dev/null. This shall not happen if job control is
              enabled. In all cases, explicit redirection of standard input shall
              override this activity.




              In sequential list, however, each command still has stdin connected to terminal if there are no explicit redirections.



              Note also, that from the definition we mentioned earlier, & executes commands in subshell. By contrast, the ; terminated list is executed in current shell. There's also difference in exit statuses. For & the standard says:




              The exit status of an asynchronous list shall be zero.




              This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 & running in background should have some way of indicating if it failed or not, however judging that you use 2>&1 you are hiding error output by redirecting, and you probably assume the script should not fail.



              By contrast, ; exit status is defined as:




              The exit status of a sequential list shall be the exit status of the
              last command in the list.




              Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.





              Side notes and additional reading




              • The fact that this is POSIX definition means that all Bourne-like shells, meaning bash, dash, and ksh must support it.


              • & in redirection is different from & as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?



              • In bash there is also |& operator ( note no space between pipe and ampersand ). From bash manual:




                If |& is used, command's standard error, in addition to its standard
                output, is connected to command2's standard input through the pipe;
                it is shorthand for 2>&1 |. This implicit redirection of the
                standard error to the standard output is performed after any
                redirections specified by the command.









              share|improve this answer





















              • 2





                What you say about & hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from /dev/null or equivalent.

                – kasperd
                Jan 5 at 17:29











              • @kasperd That's an oopsie. Fixed. Thanks !

                – Sergiy Kolodyazhnyy
                Jan 5 at 21:15











              • I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.

                – kasperd
                Jan 5 at 21:33











              • @kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)

                – Sergiy Kolodyazhnyy
                Jan 5 at 21:37
















              13














              What is the & terminator ?



              The trailing & operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:




              Asynchronous Lists



              If a command is terminated by the control operator
              ( '&' ), the shell shall execute the command
              asynchronously in a subshell. This means that the shell shall not wait
              for the command to finish before executing the next command.



              The format for running a command in the background is:



              command1 & [command2 & ... ]




              The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.



              From the definition you can see that & also serves as command terminator for lists of commands, much like ; does. In your specific example, pyprogramm >> /dev/null 2>&1 & there is only one command in the list.



              Sequential ; lists vs asynchronous & lists



              More generally,



              echo Hello ; echo World ;


              and



              echo Hello & echo World &


              are two examples of lists terminated by the ; and & operators. One difference is that & terminated list will have input connected to /dev/null if job control is disabled:




              If job control is disabled (see set, -m), the standard input for an
              asynchronous list, before any explicit redirections are performed,
              shall be considered to be assigned to a file that has the same
              properties as /dev/null. This shall not happen if job control is
              enabled. In all cases, explicit redirection of standard input shall
              override this activity.




              In sequential list, however, each command still has stdin connected to terminal if there are no explicit redirections.



              Note also, that from the definition we mentioned earlier, & executes commands in subshell. By contrast, the ; terminated list is executed in current shell. There's also difference in exit statuses. For & the standard says:




              The exit status of an asynchronous list shall be zero.




              This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 & running in background should have some way of indicating if it failed or not, however judging that you use 2>&1 you are hiding error output by redirecting, and you probably assume the script should not fail.



              By contrast, ; exit status is defined as:




              The exit status of a sequential list shall be the exit status of the
              last command in the list.




              Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.





              Side notes and additional reading




              • The fact that this is POSIX definition means that all Bourne-like shells, meaning bash, dash, and ksh must support it.


              • & in redirection is different from & as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?



              • In bash there is also |& operator ( note no space between pipe and ampersand ). From bash manual:




                If |& is used, command's standard error, in addition to its standard
                output, is connected to command2's standard input through the pipe;
                it is shorthand for 2>&1 |. This implicit redirection of the
                standard error to the standard output is performed after any
                redirections specified by the command.









              share|improve this answer





















              • 2





                What you say about & hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from /dev/null or equivalent.

                – kasperd
                Jan 5 at 17:29











              • @kasperd That's an oopsie. Fixed. Thanks !

                – Sergiy Kolodyazhnyy
                Jan 5 at 21:15











              • I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.

                – kasperd
                Jan 5 at 21:33











              • @kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)

                – Sergiy Kolodyazhnyy
                Jan 5 at 21:37














              13












              13








              13







              What is the & terminator ?



              The trailing & operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:




              Asynchronous Lists



              If a command is terminated by the control operator
              ( '&' ), the shell shall execute the command
              asynchronously in a subshell. This means that the shell shall not wait
              for the command to finish before executing the next command.



              The format for running a command in the background is:



              command1 & [command2 & ... ]




              The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.



              From the definition you can see that & also serves as command terminator for lists of commands, much like ; does. In your specific example, pyprogramm >> /dev/null 2>&1 & there is only one command in the list.



              Sequential ; lists vs asynchronous & lists



              More generally,



              echo Hello ; echo World ;


              and



              echo Hello & echo World &


              are two examples of lists terminated by the ; and & operators. One difference is that & terminated list will have input connected to /dev/null if job control is disabled:




              If job control is disabled (see set, -m), the standard input for an
              asynchronous list, before any explicit redirections are performed,
              shall be considered to be assigned to a file that has the same
              properties as /dev/null. This shall not happen if job control is
              enabled. In all cases, explicit redirection of standard input shall
              override this activity.




              In sequential list, however, each command still has stdin connected to terminal if there are no explicit redirections.



              Note also, that from the definition we mentioned earlier, & executes commands in subshell. By contrast, the ; terminated list is executed in current shell. There's also difference in exit statuses. For & the standard says:




              The exit status of an asynchronous list shall be zero.




              This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 & running in background should have some way of indicating if it failed or not, however judging that you use 2>&1 you are hiding error output by redirecting, and you probably assume the script should not fail.



              By contrast, ; exit status is defined as:




              The exit status of a sequential list shall be the exit status of the
              last command in the list.




              Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.





              Side notes and additional reading




              • The fact that this is POSIX definition means that all Bourne-like shells, meaning bash, dash, and ksh must support it.


              • & in redirection is different from & as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?



              • In bash there is also |& operator ( note no space between pipe and ampersand ). From bash manual:




                If |& is used, command's standard error, in addition to its standard
                output, is connected to command2's standard input through the pipe;
                it is shorthand for 2>&1 |. This implicit redirection of the
                standard error to the standard output is performed after any
                redirections specified by the command.









              share|improve this answer















              What is the & terminator ?



              The trailing & operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:




              Asynchronous Lists



              If a command is terminated by the control operator
              ( '&' ), the shell shall execute the command
              asynchronously in a subshell. This means that the shell shall not wait
              for the command to finish before executing the next command.



              The format for running a command in the background is:



              command1 & [command2 & ... ]




              The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.



              From the definition you can see that & also serves as command terminator for lists of commands, much like ; does. In your specific example, pyprogramm >> /dev/null 2>&1 & there is only one command in the list.



              Sequential ; lists vs asynchronous & lists



              More generally,



              echo Hello ; echo World ;


              and



              echo Hello & echo World &


              are two examples of lists terminated by the ; and & operators. One difference is that & terminated list will have input connected to /dev/null if job control is disabled:




              If job control is disabled (see set, -m), the standard input for an
              asynchronous list, before any explicit redirections are performed,
              shall be considered to be assigned to a file that has the same
              properties as /dev/null. This shall not happen if job control is
              enabled. In all cases, explicit redirection of standard input shall
              override this activity.




              In sequential list, however, each command still has stdin connected to terminal if there are no explicit redirections.



              Note also, that from the definition we mentioned earlier, & executes commands in subshell. By contrast, the ; terminated list is executed in current shell. There's also difference in exit statuses. For & the standard says:




              The exit status of an asynchronous list shall be zero.




              This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 & running in background should have some way of indicating if it failed or not, however judging that you use 2>&1 you are hiding error output by redirecting, and you probably assume the script should not fail.



              By contrast, ; exit status is defined as:




              The exit status of a sequential list shall be the exit status of the
              last command in the list.




              Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.





              Side notes and additional reading




              • The fact that this is POSIX definition means that all Bourne-like shells, meaning bash, dash, and ksh must support it.


              • & in redirection is different from & as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?



              • In bash there is also |& operator ( note no space between pipe and ampersand ). From bash manual:




                If |& is used, command's standard error, in addition to its standard
                output, is connected to command2's standard input through the pipe;
                it is shorthand for 2>&1 |. This implicit redirection of the
                standard error to the standard output is performed after any
                redirections specified by the command.










              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Jan 5 at 22:02

























              answered Jan 5 at 10:11









              Sergiy KolodyazhnyySergiy Kolodyazhnyy

              71k9147312




              71k9147312








              • 2





                What you say about & hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from /dev/null or equivalent.

                – kasperd
                Jan 5 at 17:29











              • @kasperd That's an oopsie. Fixed. Thanks !

                – Sergiy Kolodyazhnyy
                Jan 5 at 21:15











              • I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.

                – kasperd
                Jan 5 at 21:33











              • @kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)

                – Sergiy Kolodyazhnyy
                Jan 5 at 21:37














              • 2





                What you say about & hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from /dev/null or equivalent.

                – kasperd
                Jan 5 at 17:29











              • @kasperd That's an oopsie. Fixed. Thanks !

                – Sergiy Kolodyazhnyy
                Jan 5 at 21:15











              • I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.

                – kasperd
                Jan 5 at 21:33











              • @kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)

                – Sergiy Kolodyazhnyy
                Jan 5 at 21:37








              2




              2





              What you say about & hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from /dev/null or equivalent.

              – kasperd
              Jan 5 at 17:29





              What you say about & hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from /dev/null or equivalent.

              – kasperd
              Jan 5 at 17:29













              @kasperd That's an oopsie. Fixed. Thanks !

              – Sergiy Kolodyazhnyy
              Jan 5 at 21:15





              @kasperd That's an oopsie. Fixed. Thanks !

              – Sergiy Kolodyazhnyy
              Jan 5 at 21:15













              I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.

              – kasperd
              Jan 5 at 21:33





              I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.

              – kasperd
              Jan 5 at 21:33













              @kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)

              – Sergiy Kolodyazhnyy
              Jan 5 at 21:37





              @kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)

              – Sergiy Kolodyazhnyy
              Jan 5 at 21:37













              2














              It means run the command in the background. The calling script continues rather than blocking until the called command completes.






              share|improve this answer




























                2














                It means run the command in the background. The calling script continues rather than blocking until the called command completes.






                share|improve this answer


























                  2












                  2








                  2







                  It means run the command in the background. The calling script continues rather than blocking until the called command completes.






                  share|improve this answer













                  It means run the command in the background. The calling script continues rather than blocking until the called command completes.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 5 at 8:41









                  Robert LongsonRobert Longson

                  259410




                  259410























                      0














                      & this returns control of the script to the operating system but sent the response to the background not as nohup that directly sends the entire execution






                      share|improve this answer




























                        0














                        & this returns control of the script to the operating system but sent the response to the background not as nohup that directly sends the entire execution






                        share|improve this answer


























                          0












                          0








                          0







                          & this returns control of the script to the operating system but sent the response to the background not as nohup that directly sends the entire execution






                          share|improve this answer













                          & this returns control of the script to the operating system but sent the response to the background not as nohup that directly sends the entire execution







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Jan 6 at 0:40









                          BryroBryro

                          101




                          101






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Ask Ubuntu!


                              • 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%2faskubuntu.com%2fquestions%2f1107124%2fwhat-is-the-meaning-of-at-the-end-of-a-command%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

                              Human spaceflight

                              Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

                              張江高科駅