C'è un modo semplice per "riavviare" un riquadro tmux?

48

Supponiamo che io abbia una tmux(1.7) finestra divisa come segue:

 ________________________
|           1            |
|                        |
|-----------+------------|
|     2     |      3     |
|___________|____________|

Ora, le dimensioni verticali sono state personalizzate, quindi non è affatto uno dei layout predefiniti.

A volte, quando un programma si blocca o quando si riavvia un computer a cui ci si è connessi ssh, il riquadro "si blocca". Cioè nient'altro che kill-panesembra funzionare.

Tuttavia, poiché non esiste un modo semplice per ricostruire sopra la configurazione divisa una volta che il riquadro n. 1 è stato kill-paned, vorrei "riavviarlo".

tmux

— 0xC0000022L
fonte

81

Guardando il manuale, il comando respawn-panemi ha colpito, ma si è scoperto che non funzionava. Leggendo più da vicino, si è scoperto che respawn-pane -kera la risposta, dal momento che avrebbe ucciso il comando in esecuzione.

In questo modo un riquadro può essere "riavviato" e generato nuovamente in posizione.

Quindi <prefix>+ :e poi inserisci respawn-pane -ke premiEnter

— 0xC0000022L
fonte

4

Oppure usa senza -kse hai creato il riquadro in remain-on-exitmodalità e ucciso il comando da solo.

— Peter

tu hai stato deposto le uova di nuovo, in verità

— cambunctious

4

In realtà, c'è un modo per ricostruire un layout: list-windowsti dà una descrizione del layout per tutte le finestre in una sessione e select-layoutpuò digerire l'analisi della stringa e impostare il layout in modo appropriato (vedi select-layoutnella pagina man tmux(1)).

Per quanto riguarda il tuo problema ssh - i server ssh dovrebbero chiudere la connessione una volta che il sistema si è spento (anche se ho visto alcune distribuzioni Linux che in qualche modo confondono il comportamento corretto non spegnendo il demone ssh ed eseguendo correttamente le sessioni) - in tal caso, vedere la ESCAPE CHARACTERSsezione (e altri luoghi ad essa riferiti) in ssh(1)- escape carattere seguito da .(un punto) termina forzatamente la connessione sul lato client. Ovviamente non aiuta se hai appena generato il riquadro ssheseguendolo, ma se riscontri il problema più spesso, forse preferiresti eseguire una shell nel riquadro e chiamare ssh da lì.

— peterph
fonte

Ho votato a favore della tua risposta, perché aggiunge valore. Ma ecco perché i personaggi di escape non sono necessariamente una buona idea: usare una sessione ssh per connettersi a una sessione tmux che ha connessioni ssh aperte. Quindi devi improvvisamente pensare a come inviare il carattere di escape oltre la prima connessione SSH per raggiungere quello (i) interno (i). E a proposito, di solito eseguo ssh da una shell.

— 0xC0000022L

1

Praticamente la stessa cosa di quando si eseguono sessioni tmux nidificate. O hai diversi caratteri di escape nella sessione esterna e interna (sia esso ssh o tmux uno) o semplicemente invii il carattere di escape due volte - il che lo fa andare come singolo nella sessione nidificata (comportamento cablato per ssh, configurabile in tmux).

— peterph