Início / unix / Perguntas / 519782
Accepted
exit_status
Asked: 2019-05-20 02:34:24 +0800 CST

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

  • 772

Eu começo no diretório vazio.

$ touch aFile
$ ls
aFile

Então eu lsdois argumentos, um dos quais não está neste diretório. 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. Há algum perigo para esta abordagem?

io-redirection stdout

3 respostas

  1. 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 ocorra no arquivo quando ele for aberto para anexação ocorrerá no final do arquivo, independentemente de os dados virem do fluxo de saída padrão ou do 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 anexo de arquivo é atômico no UNIX?" no StackOverflow.

    Usando

    some_command >>file 2>&1

    funcionaria mesmo em NFS embora.

    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 ocorra em qualquer fluxo substituirá os dados já gravados pelo outro fluxo.

    Exemplo:

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

    A hellostring é gravada primeiro (com uma nova linha final) e, em seguida, a string abcseguida por uma nova linha é gravada a partir do erro padrão, substituindo o arquivo 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 produz apenas hellono arquivo de saída, pois essa string é escrita por último e é mais longa que a abcstring. A ordem em que os redirecionamentos ocorrem não importa.

    Seria melhor e mais seguro usar a linguagem mais idiomática

    some_command >file 2>&1
    • 22
  2. Best Answer

    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 com O_APPEND, criando dois objetos de arquivo completamente independentes[1], cada um com seu próprio estado (ponteiro, modos abertos, etc).

    Isso é muito diferente 2>&1do que é apenas chamar a chamada do dup(2)sistema e torna 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 em 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.

    barGeralmente, você pode contar com a probabilidade do arquivo foo >>bar 2>&1ser gravado ao mesmo tempo em dois locais separados, sendo bastante baixa. Mas pelo seu >>bar 2>>barvocê acabou de aumentar em uma dúzia de ordens de grandeza, sem qualquer razão.

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

    • 22

  3. Depende do que você quer alcançar. Cabe a você decidir se está tudo bem ter erros no mesmo arquivo que a saída. Isso é apenas salvar texto em um arquivo com a funcionalidade do shell que permite redirecionar como desejar. Não existe um sim ou não absoluto. Como tudo no Linux pode ser feito de várias maneiras, esta é a minha maneira ls notExistingFile existingFile >> output 2>&1 de responder à pergunta: Em termos de redirecionamento em si, sim é perfeitamente seguro.

    • 0

relate perguntas