Ctrl-C mata linha inteira enquanto Ctrl-Z não faz

Question

Estou executando vários comandos na linha de comando, separados por ponto e vírgula:

cmd1; cmd2; cmd3

Se eu pressionar Ctrl + C acima, ele irá matar todos os comandos ao invés de apenas o que está sendo executado atualmente.

kartik@kartikpc:~/junk/exp$ ls
test1  test2
kartik@kartikpc:~/junk/exp$ cat; ls
cat is running
cat is running
^C
kartik@kartikpc:~/junk/exp

Mas o Ctrl + Z só suspende o processo atual e continua com o próximo.

kartik@kartikpc:~/junk/exp$ ls
test1  test2
kartik@kartikpc:~/junk/exp$ cat; ls
cat is running 
cat is running
^Z
[1]+  Stopped                 cat
test1  test2
kartik@kartikpc:~/junk/exp$

Por que há uma dispersão no comportamento, e existe alguma maneira de fazer Ctrl + C se comportar como Ctrl + Z ?

Na verdade, estou executando um servidor através da sessão tmux como segue node app.js; $bash , e quando eu faço um Ctrl + C para matar o servidor, ele mata o bash como bem. Eu quero voltar ao shell. Existe alguma alternativa para alcançar o comportamento que eu quero?

[ATUALIZAÇÃO]

tcsh se comporta da mesma forma com Ctrl + C e Ctrl + Z . Ele sempre agiria em todos os comandos, assim como o bash está fazendo com onlt Ctrl + C . Mas trazer de volta o trabalho com fg só traria de volta cat e não ls .

[kartika@vm-kartika-vnc ~/junk]$ ls
file1  file2
[kartika@vm-kartika-vnc ~/junk]$ echo $SHELL
/bin/tcsh
[kartika@vm-kartika-vnc ~/junk]$ cat; ls
cat is running 
cat is running
^C
[kartika@vm-kartika-vnc ~/junk]$ cat ; ls
cat is running
cat is running
^Z
Suspended
[kartika@vm-kartika-vnc ~/junk]$ jobs
[1]  + Suspended                     cat
[kartika@vm-kartika-vnc ~/junk]$ fg
cat                                     // Pressing ctrl-d here to exit cat
[kartika@vm-kartika-vnc ~/junk]$ 

Informações do sistema:

kartik@kartikpc:~/junk/exp$ uname -a
Linux kartikpc 3.13.0-70-generic #113-Ubuntu SMP Mon Nov 16 18:34:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
kartik@kartikpc:~/junk/exp$ echo $SHELL
/bin/bash

    

Answer 1

Você precisa procurar controles de trabalho bash. Há uma explicação decente aqui: link

Mas, em poucas palavras, Ctrl + C mata os comandos (todos da linha) e Ctrl + Z mostrará o comando em execução. No seu caso, está fazendo o background cat (suprime a saída e interrompe o processamento) e, em seguida, continua executando o comando ls .

Você pode confirmar isso verificando a lista de processos e verá que o cat ainda está na lista.

Para trazer esse trabalho para o primeiro plano, procure no comando fg .

    

Answer 2

Se essa coisa node ...;$bash está sendo empurrada para o buffer de entrada pty por tmux , então uma solução possível é configurar o terminal apropriadamente, para trap terminal interrompe de tal maneira que afeta somente o shell interativo e usa novas linhas em vez de ; .

stty noflsh; trap : INT

^ que deve lidar com os dois primeiros requisitos.

A diferença entre um ; e um \n é devido à maneira como as shells lêem entrada - um ; ponto e vírgula é equivalente a uma nova linha na medida em que delimita as listas de comandos, mas difere na medida em que não delimita ler entrada. Por exemplo:

prompt$ cat; echo something

this the cat process
this the cat process
^C
prompt$

Mas porque eu configurei o driver tty não para liberar o buffer de entrada no recebimento de uma interrupção com stty noflsh :

prompt$ cat^Jecho something

this is the cat process
this is the cat process
^C
something
prompt$

bash readline irá realmente exibir uma nova linha literal para a combinação de teclas CTRL+V then CTRL+J em vez da fuga mostrada acima, mas o efeito é o mesmo: quando a própria shell ignora interrupções mas seus filhos não, você pode executar linhas interrompidas da entrada tty em serial, desde que o próprio terminal não descarte completamente a entrada interrompida.