Como definir permissões de arquivo específicas ao redirecionar a saída?

Provavelmente é uma duplicata, mas todas as minhas pesquisas estão levantando perguntas sobre erros de permissão negada.

Estou executando um comando em um shell bash. Quero redirecionar a saída para anexar a um arquivo que provavelmente não existe na primeira execução. Eu quero definir o modo de permissões de arquivo específico se o redirecionamento de saída precisar criar esse arquivo. Existe uma maneira de fazer isso com um comando?

Por exemplo, eu posso tentar

foo >> /tmp/foo.log 0644

onde 0644estão as permissões que eu quero foo.logterminar. A maioria dos comandos que experimentei no bash acabam interpretando 0644como um argumento adicional para foo.

Tenho a sensação de que isso vai levar um segundo comando para chmodas permissões antes ou depois de gravá-lo.

Estou usando o GNU bash 4.2.25 e o Ubuntu 12.04, se isso faz diferença - respostas gerais são preferidas.

Não há como fazê-lo durante a canalização, tanto quanto eu sei, um script simples pode ser a melhor solução.

if [ -e /tmp/foo.log ]; then
    foo >> /tmp/foo.log
else
    foo >> /tmp/foo.log
    chmod 0644 /tmp/foo.log
fi

Eu sei que é uma pergunta antiga, mas eu queria adicionar meus dois centavos.

Eu tive a mesma idéia e surgiu uma solução semelhante ao BowlesCR . O problema com a solução dele era que meu command ( foo) não funcionaria se eu alterasse o umask antes de executá-lo, então esta é a minha opinião sobre o problema:

foo | ( umask 0033; cat >> /tmp/foo.log; )

Aqui, umaskafeta apenas o redirecionamento para foo.logno subshell. Tudo o resto permanece inalterado.

Um pouco complicado, mas funciona.

Sem scripts verdadeiros, você pode encadear um pouco:

touch /tmp/foo.log; chmod 0644 /tmp/foo.log; foo >> /tmp/foo.log

Efetivamente semelhante à resposta de Slowki , mas condensado em uma linha.

A única outra coisa que consigo pensar é mexer com o umask. É melhor fazer isso em um subshell para não poluir o ambiente atual:

(umask 0033 && foo >> /tmp/foo.log)

Dois problemas com isso, no entanto.

1. O Umask não pode aumentar as permissões acima do nível especificado no creat()syscall (0666 parece ser o que o Bash usa).
2. Isso não altera as permissões em um arquivo existente (porque umaskse aplica apenas à criação do arquivo ).

Quando o redirecionamento define as permissões erradas, por exemplo:

$ rm capture.*
$ perl -e 'print STDERR "$$ STDERR\n"; print STDOUT "$$ STDOUT\n"' \
                            >> capture.STDOUT 2>> capture.STDERR
$ perl -e 'print STDERR "$$ STDERR\n"; print STDOUT "$$ STDOUT\n"' \
                            >> capture.STDOUT 2>> capture.STDERR
$ ls -l capture.*
-rw-rw-rw- 1 jcookinf jcookinf 22 Jun 12 10:38 capture.STDERR
-rw-rw-rw- 1 jcookinf jcookinf 22 Jun 12 10:38 capture.STDOUT
$ cat capture.*
215 STDERR
216 STDERR
215 STDOUT
216 STDOUT

Eu acredito que você pode usar algo como o xynomorf forneceu e abordar a preocupação stderr da Orsiris de Jong com uma pequena modificação para usar a substituição do processo do bash .

$ rm capture.*
$ perl -e 'print STDERR "$$ STDERR text\n"; print STDOUT "$$ STDOUT text\n"' \
            > >(umask 0033; cat >> capture.STDOUT) 2> >(umask 0033; cat >> capture.STDERR)
$ perl -e 'print STDERR "$$ STDERR text\n"; print STDOUT "$$ STDOUT text\n"' \
            > >(umask 0033; cat >> capture.STDOUT) 2> >(umask 0033; cat >> capture.STDERR)
$ ls -l capture.*
-rw-r--r-- 1 jcookinf jcookinf 32 Jun 12 10:43 capture.STDERR
-rw-r--r-- 1 jcookinf jcookinf 32 Jun 12 10:43 capture.STDOUT
$ cat capture.*
233 STDERR text
238 STDERR text
233 STDOUT text
238 STDOUT text

Naturalmente, use umask 0077para obter o modo 600 e proibir que outros usuários vejam o conteúdo.

Se você deseja redirecionar para um script, ao contrário umask, com substituição de processo e installtambém pode definir o bit de execução:

install -m 755 <(echo commands go here) newscript

<()coloca a saída em um arquivo temporário, consulte Substituição de Processo