Programa Bash não executado se o redirecionamento falhar

No bash, percebo que, se um comando usando o redirecionamento falhar, todos os programas executados antes dele não serão executados.

Por exemplo, este programa abre o arquivo "a" e grava 50 bytes no arquivo "a". No entanto, executar este comando com o redirecionamento para um arquivo com permissões insuficientes (~ root / log), não produz alterações no tamanho do arquivo "a".

$ ./write_file.py >> ~root/log
-bash: /var/root/log: Permission denied
cdal at Mac in ~/experimental/unix_write
$ ls -lt
total 16
-rw-rw-r--  1 cdal  staff  0 Apr 27 08:54 a <-- SHOULD BE 50 BYTES

Alguém poderia pensar que o programa seria executado, capturar qualquer saída (mas também gravar no arquivo "a") e depois falhar em gravar qualquer saída no ~ root / log. Em vez disso, o programa nunca é executado.

Por que isso e como o bash escolhe a ordem das "verificações" antes de executar um programa? Também são realizadas outras verificações?

ps Estou tentando determinar se um programa executado no cron realmente foi executado quando redirecionado para um arquivo "permissão negada".

Não se trata realmente de pedir cheques, simplesmente a ordem na qual o shell configura as coisas. Os redirecionamentos são configurados antes da execução do comando; portanto, no seu exemplo, o shell tenta abrir ~root/logpara anexar antes de tentar fazer algo que envolva ./write_file.py. Como o arquivo de log não pode ser aberto, o redirecionamento falha e o shell para de processar a linha de comando nesse ponto.

Uma maneira de demonstrar isso é pegar um arquivo não executável e tentar executá-lo:

$ touch demo
$ ./demo
zsh: permission denied: ./demo
$ ./demo > ~root/log
zsh: permission denied: /root/log

Isso mostra que o shell nem olha ./demoquando o redirecionamento não pode ser configurado.

Na página do manual do bash, seção REDIRECTION (ênfase minha):

Antes de um comando ser executado, sua entrada e saída podem ser redirecionadas usando uma notação especial interpretada pelo shell.

...

Uma falha ao abrir ou criar um arquivo causa falha no redirecionamento.

Portanto, o shell tenta abrir o arquivo de destino stdout, o que falha, e o comando não é executado.

Vale observar que o shell deve estabelecer redirecionamentos antes de iniciar o programa.

Considere o seu exemplo:

./write_file.py >> ~root/log

O que acontece no shell é:

1. Nós (a concha) fork(); o processo filho herda os descritores de arquivo aberto de seu pai (o shell).
2. No processo filho, nós fopen()(a expansão de) "~ root / log", e dup2()para fd 1 (e close()o fd temporário). Se fopen()falhar, ligue exit()para relatar o erro ao pai.
3. Ainda na criança, nós exec()"./write_file.py". Agora, esse processo não está mais executando nenhum código (a menos que tenhamos falhado em executar; nesse caso, exit()reportaremos o erro ao pai).
4. O pai deseja wait()que o filho termine e manipule seu código de saída (copiando-o para $?, pelo menos).

Portanto, o redirecionamento deve ocorrer no filho entre fork()and exec(): ele não pode acontecer antes fork()porque não deve alterar o stdout do shell e depois não exec()porque o nome do arquivo e o código executável do shell foram substituídos pelo programa Python . O pai não tem acesso aos descritores de arquivo do filho (e, mesmo que tivesse, não poderia garantir o redirecionamento entre exec()e a primeira gravação no stdout).

Lamento informar que é exatamente o contrário. O shell precisa abrir sua E / S primeiro e depois passar o controle para o programa.

tee pode ser útil neste caso: ./write_file.py | tee -a ~root/log > /dev/null