É seguro redirecionar stdout e stderr para o mesmo arquivo sem cópias do descritor de arquivo?

Eu começo no diretório vazio.

$ touch aFile
$ ls
aFile

Então, eu tenho lsdois argumentos, um dos quais não está neste diretório. Eu redireciono os dois fluxos de saída para um arquivo chamado output. Eu uso >>para evitar escrever simultaneamente.

$ ls aFile not_exist >>output 2>>output
$ cat output
ls: cannot access 'not_exist': No such file or directory
aFile

O que parece funcionar. Existem perigos para essa abordagem?

Não, não é tão seguro quanto o padrão >>bar 2>&1.

Quando você está escrevendo

foo >>bar 2>>bar

você está abrindo o bararquivo duas vezes O_APPEND, criando dois objetos de arquivo completamente independentes [1], cada um com seu próprio estado (ponteiro, modos abertos, etc.).

Isso é muito diferente do 2>&1que está apenas chamando a dup(2)chamada de sistema e cria os aliases intercambiáveis ​​stderr e stdout para o mesmo objeto de arquivo.

Agora, há um problema com isso:

O_APPENDpode levar a arquivos corrompidos nos sistemas de arquivos NFS se mais de um processo anexar dados a um arquivo de uma só vez. Isso ocorre porque o NFS não suporta anexar a um arquivo, portanto o kernel do cliente precisa simulá-lo, o que não pode ser feito sem uma condição de corrida.

Você geralmente pode contar com a probabilidade do arquivo como barem foo >>bar 2>&1sendo gravados ao mesmo tempo em dois lugares separados sendo bastante baixa. Mas, pelo seu, >>bar 2>>barvocê apenas o aumentou em uma dúzia de ordens de magnitude, sem qualquer motivo.

[1] "Abrir descrições de arquivo" na linguagem POSIX.

O que acontece quando você faz

some_command >>file 2>>file

é que fileserá aberto para anexar duas vezes. Isso é seguro em um sistema de arquivos POSIX. Qualquer gravação que aconteça no arquivo quando ele for aberto para anexar ocorrerá no final do arquivo, independentemente de os dados chegarem ao fluxo de saída padrão ou ao fluxo de erro padrão.

Isso depende do suporte para operações de gravação de acréscimo atômico no sistema de arquivos subjacente. Alguns sistemas de arquivos, como o NFS, não suportam anexos atômicos. Veja, por exemplo, a pergunta "O arquivo é anexado atômico no UNIX?" No StackOverflow.

Usando

some_command >>file 2>&1

funcionaria mesmo no NFS.

No entanto, usando

some_command >file 2>file

não é seguro, pois o shell truncará o arquivo de saída (duas vezes) e qualquer gravação que ocorrer em um fluxo substituirá os dados já gravados pelo outro fluxo.

Exemplo:

$ { echo hello; echo abc >&2; } >file 2>file
$ cat file
abc
o

A hellosequência é gravada primeiro (com uma nova linha final) e, em seguida, a sequência abcseguida por uma nova linha é gravada a partir do erro padrão, substituindo a hell. O resultado é a string abccom uma nova linha, seguida pelo que resta da primeira echosaída, uma oe uma nova linha.

Trocar os dois echoao redor do ferimento produz apenas hellono arquivo de saída, pois a sequência é escrita por último e é maior que a abcsequência. A ordem na qual os redirecionamentos ocorrem não importa.

Seria melhor e mais seguro usar o método mais idiomático

some_command >file 2>&1

Depende do que você deseja alcançar. Cabe a você decidir se há erros no mesmo arquivo que a saída. Isso é apenas salvar o texto em um arquivo com a funcionalidade do shell, que permite redirecionar conforme desejado. Não existe um sim ou não absoluto. Como tudo no Linux, isso pode ser feito de várias maneiras, este é o meu caminho ls notExistingFile existingFile >> output 2>&1 Para responder à pergunta: Em termos de redirecionamento, sim, é perfeitamente seguro.