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

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.

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

& 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