razão para exec em scripts de wrapper

Question

Eu vi exemplos de scripts de wrapper que, em um nuthell, estão seguindo:

#!/bin/bash

myprog=sleep
echo "This is the wrapper script, it will exec "$myprog""

exec "$myprog" "$@"

Como visto acima, eles usam exec para substituir o shell recém-criado quase imediatamente com o $myprog . Pode-se conseguir o mesmo sem exec :

#!/bin/bash

myprog=sleep
echo "This is the wrapper script, it will exec "$myprog""

"$myprog" "$@"

Neste último exemplo, uma nova instância do bash é iniciada e, em seguida, o $myprog é iniciado como um processo filho da instância do bash.

Quais são os benefícios da primeira abordagem?

    

Answer 1

Usar exec torna o wrapper mais transparente, ou seja, é menos provável que o usuário ou aplicativo que chama o script precise estar ciente de que é um revezamento que, por sua vez, inicia o programa "real".

Em particular, se o chamador quiser matar o programa, ele simplesmente matará o processo que acabou de lançar. Se o script wrapper executar um processo filho, o chamador precisará saber que ele deve descobrir o filho do wrapper e eliminá-lo. O script wrapper poderia definir uma armadilha para retransmitir alguns sinais, mas isso não funcionaria com SIGSTOP ou SIGKILL, o que não pode ser detectado.

Chamar exec também economiza um pouco de memória (e outros recursos, como PIDs, etc.), já que não há necessidade de manter um shell extra sem nada a fazer.

Se houver vários wrappers, os problemas se somam (dificuldade em encontrar o processo correto para matar, sobrecarga de memória, etc.).

Alguns shells (por exemplo, o shell Korn) detectam automaticamente quando um comando é o último e não há interceptação ativa e coloca um implícito exec , mas nem todos fazem (por exemplo, não bash).

    

Answer 2

Não encontrando duplicatas ... consulte o Manual do FreeBSD , o que dá uma boa razão:

The exec statement replaces the shell process with the specified program. If exec is omitted, the shell process remains in memory while the program is executing, and needlessly consumes system resources.

que é essencialmente a razão explicada há um tempo atrás (por um dos porteiros), e é bastante conhecida.