- Shell handling --- The shell edits the command (splitting it to different rows etc)
Sim, mais ou menos. O shell obtém um comando como uma única string (geralmente uma linha de entrada) e o transforma em um conjunto de strings que realmente vão para o executável que eventualmente executa. O shell divide as palavras separadas por espaços em branco de uma única string em várias strings, mas também manipula aspas e expande as variáveis, etc.
Então, algo como
ls "$options" "/filename with spaces"
pode resultar nas três sequências ls
, -l
(do valor de $options
) e /filename with spaces
(remoção de cotações). Esses são passados para a chamada do sistema exec()
que executa o programa.
and all of this is done in a different shell than the current one.
Não, não realmente. Algumas expansões de shell (como $( ... )
) geram subshells para fazer o trabalho pesado, mas isso não acontece com uma linha de comando "simples" regular.
- Execution of the outcome after shell handling (in the original shell we work with).
Realmente executar o programa como após a linha de comando ser analisada é uma etapa logicamente separada. Mas tecnicamente isso acontece em outro processo, já que a maneira de executar outro programa no Unix envolve primeiramente chamar fork()
, que cria um novo processo como uma cópia do primeiro, e chamando exec()
para substituir essa cópia (do shell) com o programa real a ser executado (por exemplo, ls
no exemplo).
Se o comando for iniciado com exec
(como em exec ls
, o bifurcação será ignorado e o shell será substituído pelo comando que está sendo iniciado.
Como mencionado nos comentários, os shell builtins (como echo
em muitos shells) também são executados no mesmo processo, sem bifurcação.
(Todos os itens acima são um pouco simplificados. Os shells reais podem ter outros recursos que não estão descritos aqui.)