molto lento per interrompere il processo con Ctrl-C

Se eseguo un comando con molto output in tmux, ma decido di annullarlo con Ctrl-C, c'è un ritardo di 10-15 secondi prima che si fermi. Tuttavia, se faccio la stessa cosa al di fuori di tmux, si interrompe immediatamente. Perché è questo ed è riparabile?

In pratica, questo problema si presenta quando sto facendo grep -Rsu una directory di grandi dimensioni e la mia ricerca non è abbastanza limitata. Una soluzione alternativa sarebbe quella di convogliare il risultato per wcprimo per assicurarsi che l'output non sia troppo lungo, ma questo è solo un altro passo che vorrei evitare.

Appunti:

• Questo ha lo stesso comportamento in Gnome Terminal, uxterm, st e un semplice terminale virtuale (ad esempio, ctrl-alt-f2), ma il ritardo è inferiore nel semplice terminale virtuale.
• Non sono l'unico: http://www.mail-archive.com/tmux-users@lists.sourceforge.net/msg01569.html
• Il ritardo è più lungo se la finestra del mio terminale è più grande. Per un terminale a schermo intero, sono necessari circa 15 secondi per arrestarsi grep -R(nessun altro argomento) in una directory home ingombra. Per un terminale di 80 × 25 caratteri, si ferma quasi immediatamente.

tmux ora ha le seguenti opzioni:

c0-change-interval interval
c0-change-trigger trigger

È possibile impostare valori per questi, che renderanno più facile scrivere ^ C e gli amici. Vedi man tmux:

Queste due opzioni configurano una semplice forma di limitazione della velocità per un riquadro. Se tmux vede più che innescare sequenze C0 che modificano lo schermo (ad esempio, ritorni a capo, avanzamenti di riga o spazi posteriori ) in un millisecondo, interromperà immediatamente l'aggiornamento del riquadro e lo ridisegnerà interamente ogni intervallo di millisecondi. Questo aiuta a prevenire un'uscita veloce (come sì (1)) che travolge il terminale. L'impostazione predefinita è un trigger di 250 e un intervallo di 100. Un trigger di zero disabilita il limite di velocità.

È sempre possibile inviare un kill-panecomando dall'interno della sessione. Se il testo del terminale sembra immondizia, rinominare la finestra e / o rilasciare resetdovrebbe risolverlo.

Poiché si tmuxsta inserendo tra il catprocesso e il terminale, deve leggere l'output da cat, scriverlo sul terminale e allo stesso tempo leggere l'input dal terminale (il ^ C) e inviarlo alla shell per interrompere il comando. Non sono sicuro di cosa causi il ritardo, ma è qualcosa su come tmuxbuffer I / O tra te e la shell che gira tmux.

Supponendo che tu stia usando ssh su una connessione a bassa latenza, hai provato a usare mosh ? Tra le altre cose molto belle come la previsione dell'input, le disconnessioni sopravvissute e persino un IP che cambia sul lato client, migliora anche in particolare il tempo di reazione quando si utilizza Ctrl-C (aggiornando periodicamente solo i contenuti del terminale invece di inviare l'intero flusso) .

È possibile utilizzare tmuxall'interno moshsenza alcun problema.

Ho riscontrato questo problema con tmux 2.3. Ho provato a impostare le opzioni c0-change-intervallo e c0-change-trigger come descritto sopra, ma non sono più disponibili. Ecco la modifica git con la nuova soluzione tentata: https://github.com/tmux/tmux/commit/3f4ee98162cd5bb7000f93fec0e631e123b1281d

Il ripristino di tmux 1.8 ha risolto il problema per me senza dover impostare alcuna opzione.