Running a process in the background with I / O redirection

Question

I am curious to know if it matters where the & operator is used in the code when the process has an I / O redirection to start the process in the background.

What are the differences / there are differences between these lines of code in terms of starting the process in the background. If so, how can I determine what the differences will be?

setsid python script.py < /dev/zero &> log.txt & setsid python script.py < /dev/zero & > log.txt & setsid python script.py < /dev/zero > log.txt & setsid python script.py & < /dev/zero > log.txt 

Answer 1

Managing operator

There are two uses of & . One of them is the so-called control operator. . Each command ends with a control statement such as & ; or <newline> . The difference between the two is that ; and <newline> execute the command in the foreground, and & in the background.

 setsid python script.py < /dev/zero & > log.txt & setsid python script.py & < /dev/zero > log.txt 

These two lines, therefore, actually execute two commands each. The first is equivalent to two commands:

 setsid python script.py < /dev/zero & > log.txt & 

And the second is equivalent:

 setsid python script.py & < /dev/zero > log.txt 

If you're interested, yes, > log.txt and < /dev/zero > log.txt are both legal commands. Without a command name, they simply handle redirects: each creates an empty file called log.txt .

Redirection

 setsid python script.py < /dev/zero &> log.txt & 

This version with &> is different from the version with & > . &> without space - a special redirection operator in bash that redirects both stdout and stderr.

 setsid python script.py < /dev/zero > log.txt & 

This final version is similar to the previous one, but only redirects stdout to log.txt . stderr continues to go to the terminal.

Answer 2

So & means different things, depending on context.

In the first case:

 setsid python script.py < /dev/zero &> log.txt & 

the first & used along with > like &> , which means redirecting both stderr and stdout. Last & means run in background

In the second case:

 setsid python script.py < /dev/zero & > log.txt & 

You only have the first & , which, as stated above, means, but the process is in the background, in this case it setsid python script.py < /dev/zero , which is placed in the background. Then the rest of the line says: do not redirect the process to the log.txt file and do not create it, something like nonsense.

In the third case:

 setsid python script.py < /dev/zero > log.txt & 

You have & at the end, so all this is put in the background, however your redirect only redirects stdout to log.txt, not stderr, as in the first case.

In the latter case:

 setsid python script.py & < /dev/zero > log.txt 

You put setsid python script.py in the background and redirect stdout nothing to log.txt and put /dev/zero in stdin nothing.

Answer 3

It matters. & doubles as a command delimiter (same as ; is a command delimiter). What are you really doing in something like

 setsid python script.py & < /dev/zero > log.txt 

setsid python script.py in the background, and also runs the "null" command (which appears after & ) in the foreground (additional & at the end will run it in the background). This null command has its own stdin redirected to / dev / zero, and its stdout redirects to log.txt.

In addition, &> is a special operator in Bash. foo &>out redirects both stdout and stderr while foo running. This is not the same as foo & >out , which runs foo in the background, also redirects the output of a null command.

(This support for null commands is why idioms like >foo on a separate line, which you sometimes see in shell scripts, work to trim a file.)