Quando vuoi reindirizzare sia stdout che stderr sullo stesso file, puoi farlo usando command 1>file.txt 2>&1, o command &>file.txt. Ma perché il comportamento è command 1>file.txt 2>file.txtdiverso dai due comandi precedenti?

Di seguito è riportato un comando di verifica.

$ cat redirect.sh
#!/bin/bash

{ echo -e "output\noutput" && echo -e "error" 1>&2; } 1>file.txt 2>&1
{ echo -e "output\noutput" && echo -e "error" 1>&2; } 1>file1.txt 2>file1.txt
{ echo -e "error" 1>&2 && echo -e "output\noutput"; } 1>file2.txt 2>file2.txt
{ echo -e "output" && echo -e "error\nerror" 1>&2; } 1>file3.txt 2>file3.txt
{ echo -e "error\nerror" 1>&2 && echo -e "output"; } 1>file4.txt 2>file4.txt

$ ./redirect.sh

$ echo "---file.txt---"; cat file.txt;\
echo "---file1.txt---"; cat file1.txt; \
echo "---file2.txt---"; cat file2.txt; \
echo "---file3.txt---"; cat file3.txt; \
echo "---file4.txt----"; cat file4.txt;
 ---file.txt---
output
output
error
---file1.txt---
error

output
---file2.txt---
output
output
---file3.txt---
error
error
---file4.txt----
output
rror

Per quanto riguarda i risultati, sembra che la seconda stringa di eco sovrascriva la prima stringa di eco quando si esegue command 1>file.txt 2>file.txt, ma non so perché lo farà. (C'è un riferimento da qualche parte?)

Devi sapere due cose:

• Un descrittore di file aperto noto al lato della modalità applicazione di un processo fa riferimento a un oggetto kernel interno noto come descrizione del file , che è un'istanza di un file aperto. Possono esistere più descrizioni di file per file e più descrittori di file che condividono una descrizione di file.
• La posizione corrente del file è un attributo di una descrizione del file . Pertanto, se più descrittori di file sono associati a una singola descrizione di file, condividono tutti la stessa posizione corrente del file e una modifica alla posizione del file attuata utilizzando uno di questi descrittori di file influisce su tutti gli altri descrittori di file.

  Tali modifiche sono emanate dai processi chiamando i read()/ readv(), write()/ writev(), lseek()chiamate, e di sistema simili. Il echocomando chiama write()/ writev()ovviamente.

Quindi quello che succede è questo:

• command 1>file.txt 2>&1crea solo una descrizione del file, perché la shell apre un file solo una volta. La shell rende sia l'output standard sia i descrittori di file di errore standard associati alla descrizione di quel singolo file. Si duplica standard output su errore standard. Quindi una scrittura tramite uno dei descrittori di file sposta la posizione corrente del file condiviso: ogni scrittura va dopo la precedente la descrizione del file comune. E come puoi vedere i risultati dei echocomandi non si sovrascrivono l'un l'altro.
• command 1>file.txt 2>file.txtcrea due descrizioni dei file, poiché la shell apre due volte lo stesso file, in risposta ai due reindirizzamenti espliciti. I descrittori di file di output standard e di errore standard vengono associati a due diverse descrizioni di file, che a loro volta vengono mappate allo stesso singolo file. Le due descrizioni dei file hanno posizioni di file correnti completamente indipendenti e ogni scrittura passa immediatamente alla scrittura precedente sulla stessa descrizione del file. E come puoi vedere il risultato è che ciò che è scritto tramite uno può sovrascrivere ciò che è scritto tramite l'altro, in vari modi in base all'ordine in cui esegui le scritture.

Ulteriori letture

• Cos'è una descrizione del file aperto?
• Cos'è esattamente un offset di file nell'output di lsof?

L'utilizzo >indica di sovrascrivere il file. Dato che stdout e stderr sono scritti nel file in due diverse operazioni, l'ultimo da scrivere sovrascriverà il primo.

Tu puoi fare:

command 1>>file.txt 2>>file.txt

o

command &>file.txt Bash v4 e versioni successive.

>> gli dice di aggiungere il file in modo che non sostituisca l'output delle operazioni precedenti.

&> è solo un modo più semplice per scrivere 2>&1