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












8














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





























    8














    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



























      8












      8








      8


      2





      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 yesterday









      Zanna

      50.2k13133241




      50.2k13133241










      asked 2 days ago









      vicovico

      1,15472345




      1,15472345






















          3 Answers
          3






          active

          oldest

          votes


















          12














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










          • @kasperd That's an oopsie. Fixed. Thanks !
            – Sergiy Kolodyazhnyy
            2 days ago










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










          • @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
            2 days ago



















          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








            New contributor




            Bryro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.


















              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









              12














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










              • @kasperd That's an oopsie. Fixed. Thanks !
                – Sergiy Kolodyazhnyy
                2 days ago










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










              • @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
                2 days ago
















              12














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










              • @kasperd That's an oopsie. Fixed. Thanks !
                – Sergiy Kolodyazhnyy
                2 days ago










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










              • @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
                2 days ago














              12












              12








              12






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

























              answered 2 days ago









              Sergiy KolodyazhnyySergiy Kolodyazhnyy

              70.1k9144307




              70.1k9144307








              • 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
                2 days ago










              • @kasperd That's an oopsie. Fixed. Thanks !
                – Sergiy Kolodyazhnyy
                2 days ago










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










              • @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
                2 days ago














              • 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
                2 days ago










              • @kasperd That's an oopsie. Fixed. Thanks !
                – Sergiy Kolodyazhnyy
                2 days ago










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










              • @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
                2 days ago








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




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












              @kasperd That's an oopsie. Fixed. Thanks !
              – Sergiy Kolodyazhnyy
              2 days ago




              @kasperd That's an oopsie. Fixed. Thanks !
              – Sergiy Kolodyazhnyy
              2 days ago












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




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












              @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
              2 days ago




              @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
              2 days ago













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









                  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








                      New contributor




                      Bryro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                      Check out our Code of Conduct.























                        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








                        New contributor




                        Bryro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                        Check out our Code of Conduct.





















                          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








                          New contributor




                          Bryro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.









                          & 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








                          New contributor




                          Bryro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.









                          share|improve this answer



                          share|improve this answer






                          New contributor




                          Bryro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.









                          answered 2 days ago









                          BryroBryro

                          101




                          101




                          New contributor




                          Bryro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.





                          New contributor





                          Bryro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.






                          Bryro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.






























                              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.





                              Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                              Please pay close attention to the following guidance:


                              • 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

                              Сан-Квентин

                              Алькесар

                              Josef Freinademetz