Ambos exec
e env
não bifurcam, veja o exemplo a seguir:
docker run --rm -it ubuntu:18.04 sh -c 'exec sleep 1 & ps -Ho pid,ppid,cmd'
PID PPID CMD
1 0 sh -c exec sleep 1 & ps -Ho pid,ppid,cmd
7 1 sleep 1
8 1 ps -Ho pid,ppid,cmd
docker run --rm -it ubuntu:18.04 sh -c 'env sleep 1 & ps -Ho pid,ppid,cmd'
PID PPID CMD
1 0 sh -c env sleep 1 & ps -Ho pid,ppid,cmd
7 1 sleep 1
8 1 ps -Ho pid,ppid,cmd
Pergunta
Vejo muita gente usando exec env ...
mas acho que não exec
é necessário porque env
não bifurca igual o exec
.
Existe algum caso de uso que precisamos usar exec env
em vez de env
?
env
(provavelmente) não se bifurca, apenas se substitui pelo programa que faz. Mas isso é diferente do shell pai bifurcandoenv
ou apenas substituindo-se porenv
.Por exemplo, compare estes dois:
Com
exec
, o próprio shell é substituído e o seguinteecho
não é executado.Claro, você tinha
exec env ... &
em vez disso. Com&
, o shell bifurca de qualquer maneira para iniciar o processo em segundo plano e pode não bifurcar novamente para executar o único comando na tarefa em segundo plano. Pelo menos o Bash otimiza casos como esse, por exemplo:onde o último não mostra o
bash
processo intermediário, o comportamento é o mesmo que se houvesse umexec
lá. (-/bin/bash
é meu shell interativo.)Bash só faz isso para um comando sozinho, se houver mais de um, o shell espera que o último saia. Usar
exec
lá faria a diferença:Com
&
, isso seria o mesmo comexec ps
:Mas com um bloco composto, vemos o processo do shell em segundo plano também:
Você não forneceu nenhuma fonte específica para essas muitas pessoas fazendo
exec env
isso, então não sabemos a situação exata delas. Mas você usariaexec env
da mesma maneira queexec anyprogram
: se quiser substituir o shell por algum outro processo. Por exemplo, este exemplo simulado:O
exec
lá substitui o script pelo programa iniciado, para que o shell não permaneça na memória inutilmente. Além disso, se no script houver apenas um intermediário para iniciar o programa, fazer umexec
vai manter o PID igual, o que facilita para o pai (do script e depois do programa) monitorar seu filho.