Na Unixlinha de comando, se eu pressionar Ctrl-C, isso não encerra um processo, mas o interrompe e eu volto ao prompt do shell.
Então, eu tenho as duas perguntas a seguir:
Respostas:
Ctrl+ Cenvia um SIGINT. Por padrão, isso encerra o aplicativo.
Você está confundindo isso Ctrl-Z, o que suspende um aplicativo no bash.
Historicamente, havia três sinais ligados às teclas que eram
Em alguns sabores * nix, há outros sinais também ligados, você pode verificar as ligações do teclado usando o comando
stty -a
No meu sistema, OS / X, isso produz a seguinte saída
speed 9600 baud; 65 rows; 213 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
Observe que matar neste caso não é um sinal de KILL que está relacionado à limpeza do buffer de entrada atual.
Você pode ter mais sucesso ao interromper processos usando SIGQUIT, mas isso pode não ser verdade, pois o processo pode capturar o sinal e ignorá-lo.
Não há conceito de uma lista de processos "interrompidos", pois o processo capturou e ignorou a interrupção ou saiu. Você pode obter uma lista de processos suspensos digitando trabalhos
Muitas respostas corretas, mas nenhuma que esteja completa.
Para encerrar com extremo preconceito e sem permitir que o processo pare, use SIGKILL, que não está vinculado a nenhuma chave por padrão. Em vez disso, você geralmente o envia usando o kill (1)comando e especificando o sinal para enviar como em
$ kill -9 <process ID>
ou mnemonicamente
$ kill -KILL <process ID>
Esse sinal é tratado diretamente pelo sistema operacional e o programa não pode substituir o comportamento padrão.
Se o seu shell suportar o controle de tarefas, ele também poderá suportar uma versão integrada, killque suporta a identificação de tarefas usando o %caractere como na resposta da passarela .
fgcontinuar no controle do terminal ou bgconfigurá-lo em execução sem manter o controle do terminal (mas, por padrão, ainda envia sua saída para lá).para ver a lista de processos em segundo plano: jobs
matar: kill %1(substitua 1 pelo ID do trabalho correspondente como na jobssaída)
Ctrl-C envia SIGINT, que por padrão faz com que um processo termine, mas pode ser interceptado (dentro \bin sh, usando trap).
SIGKILL é o sinal de interrupção incontrolável.
Editar Terceira vez, acho que está certo: verifiquei tudo com relação aos documentos. Veremos.
Isso não está claro para a maioria dos iniciantes do terminal, mas se o problema for apenas o de você estar em um programa interativo e não conseguir descobrir como sair, muitas vezes qsairá. Por exemplo, esta é a chave para sair less, que também é o programa que você obtém ao visualizar manpáginas, entre outras coisas.
Alguns programas têm outros atalhos de teclado para sair. Em vimou vi, use ESC:wq. Em emacs, use Control-C Control-X. Em nanoou pico, use Control-X. Observe que, nesses exemplos, há sutilezas, em particular, sobre se esses atalhos salvam ou não as alterações que você possa ter feito no arquivo que está sendo editado.
Muitos processos podem instalar um manipulador de interrupção para capturar o sinal de interrupção, mas aqueles que não o fizerem serão cancelados por padrão.
Para forçar a saída de um processo, você pode enviar SIGQUIT (Ctrl- \).
Parece que as outras respostas são o cenário provável, mas também é possível que você esteja executando um script que não lida com seus filhos corretamente. Recentemente, cheguei a um cenário semelhante, em que matar um script não mataria os processos filhos desse script.
Em geral, se você entrar nessa situação, precisará revisar todos os processos que está executando. Você deve revisar a página de manual do ps. ( man ps) Gosto particularmente de usar ps auxwf, que mostra a relação pai / filho entre processos. pstreefaz algo semelhante. Você deve executá-lo em outro terminal antes de interromper o processo para ver como são as coisas na situação normal e identificar os processos filhos.
Se você matar (com ^ C) esse processo principal, verifique novamente a saída do ps para ver se alguma coisa mudou. Se os processos filhos ainda estiverem por aí, você poderá matá-los com o killcomando (ver man kill)
stty -ixonpara que eles passassem. Eu acho que eles mudariam para<undef>.