Quando um shell executa um builtin, e um sinal é gerado pelo teclado, o que irá lidar com o sinal?

Question

Por favor corrija-me se estiver errado: Quando um bash shell executa um programa executável externo , o bash shell criará um processo-filho para executar o programa em primeiro plano. Se houver algum sinal gerado por chave, o sinal será enviado para o processo filho e manipulado por programa.

Quando um shell bash executa um comando interno , o bash shell executará o comando incorporado no processo do shell diretamente em primeiro plano. Se houver algum sinal gerado por chave, o sinal será enviado para o processo de shell? Que irá lidar com o sinal, o programa do comando incorporado ou bash ? Um comando interno pode ter seu próprio manipulador de sinal ou ele precisa depender dos manipuladores de sinal de bash ?

Por exemplo, quando um shell bash está executando wait em primeiro plano e eu pressiono Ctrl-C, o sinal SIGINT será recebido pelo processo shell e tratado por wait ou por bash? O wait tem seu próprio manipulador de sinal ou depende do manipulador de sinal de bash ?

Obrigado.

    

Answer 1

A maneira mais fácil de entender os dispositivos terminais Linux ( /dev/tty* , /dev/pts/* ) é como você pensa neles como streaming sockets . Como se o /dev/tty12 fosse uma porta TCP, como 127.0.0.1:8080 .

Os processos estão conectando-os, obtêm informações deles, escrevem neles e, finalmente, os desconectam. Um soquete (terminal) pode ter uma conexão com vários processos.

Outros processos podem escutá-los , eles são tipicamente os programas de emulador de terminal, mas nem sempre. No caso dos terminais de caracteres, o próprio kernel Linux funciona como um "daemon ouvinte" no dispositivo terminal.

O "recurso extra" que um terminal tem, mas um socket não tem: o kernel controla quais processos estão conectando-o, e é capaz de sinalizá-los sobre a necessidade . Então acontece, por exemplo, se você pressionar ctrl / c.

Uma lista detalhada dos sinais passados que você pode ler em esta resposta.

O que exatamente acontece se você pressionar ctrl / c?

Não é se alguém pressionar um botão normal, por exemplo, uma tecla "a". Nesse caso, a tecla pressionada é simplesmente gravada no dispositivo terminal e pode ser lida pelos processos que leem a partir dela (o que geralmente é o processo em primeiro plano).

No caso de um pressionamento de tecla tão extraordinário, por exemplo, ctrl / z, ou você fecha / redimensiona a janela do terminal, e assim por diante, o terminal obtém o pedido e o kernel envia para todos os processos anexados o sinal correspondente . Para todos eles, será importante mais tarde.

Esses dispositivos também podem ser controlados por chamadas ioctl() bem direcionadas.

Se o bash executar um subprocesso (ou seja, um comando externo), ocorrerá o seguinte:

1. bash inicia o processo em segundo plano, dando a ele o terminal
2. o bash pára de receber entrada do terminal
3. depois que o processo parar, o bash define tudo de volta.

No entanto, o bash permanece conectado ao dispositivo terminal e, se um ctrl / c estiver chegando, ele receberá o sinal. Além disso, o comando externo receberá o sinal.

No entanto, esses sinais podem ser substituídos ( signal() , sigaction() system calls). O Bash substitui-os, isto é, substitui a rotina padrão de manipulação de sinais (que simplesmente a interrompe) por sua própria. É por isso que não sai se você pressionar ctrl / c em um prompt de comando.

No entanto, um sleep 60 será encerrado. Não altera seus manipuladores de sinais.

Se você executar um comando interno bash, este manipulador de sinal funcionará como você disse (ele interrompe a execução do comando interno e o leva de volta ao prompt).

    

Answer 2

Which will handle the signal, the builtin command's program or bash?

O programa do comando incorporado é bash. Essa é a definição de um builtin: ele é construído no shell, não é um programa externo.

O shell pode reagir de maneira diferente dependendo do que está fazendo quando recebe um sinal. Mas é sempre o processo de shell que recebe o sinal, já que não há outro processo envolvido.