Tmux i praksis: lokale og nestede tmux-sessioner

Vi diskuterer tmux-funktioner, deres relevans for lokale og eksterne scenarier, og hvordan man opsætter og konfigurerer tmux til at understøtte indlejrede sessioner

Dette er den første del af min tmux i artikelserier i praksis. Det handler om at bruge og konfigurere tmux v2, lokal og ekstern tmux-session brug, og hvordan man understøtter et scenarie, når en ekstern tmux-session skal indlejres i en lokal tmux-session.

Inden du begynder at læse, er her et fungerende eksempel fra min maskine. Vi har en lokal tmux-session på OSX inde i iTerm2 (kører i fuldskærmstilstand). Den lokale session har to vinduer: “zsh” og “node”.

Vinduet “zsh” er opdelt i 2 ruder: i begge ruder SSH'ede vi til fjernværterne (CentOS7 og Ubuntu14) og hoppede ind i eksterne tmux-sessioner der.

Den nederste rude med Ubuntu14-fjernsessionen er yderligere opdelt i 2 ruder, og vi har 3 vinduer: shell, mon og logs.

Hvis du er nysgerrig, hvordan det hele fungerer sammen, skal du fortsætte med at læse.

Funktioner

Lad os først gennemgå tmux-funktioner og fordele for at forstå deres relevans for lokale eller eksterne scenarier. Vi bør afklare for os selv, hvorfor vi har brug for denne "indlejrede tmux in tmux"-ting, fordi det ved første øjekast ser ret vildt ud.

  1. Terminal multiplexing, navngivne vinduer, opdelt vindue i flere ruder. Dette giver mere mening for det lokale miljø, når du beslutter at overbelaste din terminalemulator, som ellers ikke understøtter ovennævnte funktioner. For eksempel er iTerm eller Terminator allerede i stand til at multipleksere en terminal.
  2. Opsæt og start tmux-session med et forudkonfigureret sæt vinduer og ruder, deres arrangement og kommandoer kører inde for at undgå besværet med gentagne gange at opsætte dem igen og igen fra bunden. For eksempel:

    - "dev" -session, som inkluderer vinduet "# 1: shell" med 2 ruder til ad hoc-brug

    - “# 2: overvågning” vindue med htopog sysdigruder

    - “# 3: log” -vindue med journalctlog tail -f app.logruder

    - "# 4: node" -vindue, der kører nodeserver

    tmux lader dig skrive script for at opnå dette, og hvis du foretrækker den konfigurationslignende tilgang, skal du kigge på tmuxinator. Dette er relevant for både lokale og eksterne scenarier.

  3. Fortsæt din arbejdstilstand, så du kan frigøre og genoptage senere med samme tilstand som du forlod. Når du arbejder lokalt med flere projekter, kan du opsætte flere tmux-sessioner pr. Projekt og nemt skifte kontekst

    På den eksterne maskine kan du løsne dig fra sessionen ved slutningen af ​​en arbejdsdag og komme tilbage til den samme session hjemmefra om aftenen.

  4. Overlev pludselige forbindelsesfald. Dette er en af ​​de vigtigste træk. Antag at du SSH på fjernhost og har en langvarig proces der. Hvis SSH-forbindelsen går tabt, eller der opstår fysisk netværksfald, sendes SIGHUP-signal til den eksterne skal, og den og alle dens underordnede processer vil blive afsluttet. Tmux gør dine eksterne processer modstandsdygtige over for sådanne risici.

Mindre vigtige funktioner, men stadig værd at nævne er som følger:

  1. Når du har konfigureret tmux-miljøet, er du mindre afhængig af moderterminalemulatoren og dens unikke sæt funktioner , og du kan skifte til en anden terminalemulator, der bliver mindre besværlig. Da jeg er iTerm2 på OSX-bruger, kan jeg migrere til Terminator eller konsole på Linux ved at installere min tmux-konfiguration der og få det samme kendte miljø, som jeg allerede er vant til.
  2. Del din fjernsession med din kollega, så du kan samarbejde i realtid. Jeg synes, det er sjældent brug i en rigtig verden, men lyder cool. Ja, par programmering og andre seje buzzwords. ?

Så for at konkludere er tmux ansvarlig for to hoved ting :

  1. Terminalmultiplexing, session / vindue / rudehåndtering
  2. Fortsæt sessionstilstand og overlev frakoblinger til fjernscenarier

Hvor tmux virkelig skinner er (2). Med hensyn til (1) hævder nogle mennesker, at tmux bryder Unix-filosofi, fordi det forsøger at gøre 2 ting i stedet for at gøre en og gøre det godt, og at (1) ikke bør være et tmux-ansvar.

Indlejrede lokale og eksterne sessioner

Så i betragtning af alt det foretrækker nogle mennesker at bruge tmux på den lokale maskine kun oven på deres terminalemulator, hvilket overbelaster det med multiplexing og vinduesstyring i første omgang. Folk, der brugte det meste af deres tid på at SSH'e på eksterne værter, benytter sig af vedvarende sessionsnatur og modstand mod netafbrydelser.

Men skal lokale og fjerntliggende sager udelukke hinanden? Kan jeg kombinere dem? Ja, det er lovligt at SSH til en ekstern vært og starte tmux-sessionen der, mens du allerede er i et tmux-miljø lokalt.

Dette kaldes indlejrede sessioner, men kommer med nogle forhindringer:

Først og fremmest står du over for spørgsmålet: Hvordan kan du kontrollere indre sessioner, da alle tastebindinger fanges og håndteres af ydre sessioner?

Den mest almindelige løsning er at trykke prefixto gange (præfikset er en tastebinding, der sætter tmux i en kommandotilstand, normalt er det C-b, men nogle foretrækker at omlægge det til skærmlignende C-a). Det første præfiks-tastetryk bliver fanget af den ydre session, hvorimod den anden sendes til den indre session. Der er ikke behov for ekstra trin, og dette fungerer ud af kassen.

Imidlertid er rodtastebindinger - dem, der er lyttet globalt, ikke i kommandotilstand - stadig kun fanget af den ydre session. Og jeg fandt det virkelig irriterende at dobbeltklikke prefix. For mig er det endda irriterende at trykke på det en gang, i iTerm2 er der ikke noget som kommandotilstand, og jeg trykker bare på “ ⌘⌥→” for at vælge rude til højre i stedet for at sende to separate tastetryk C-a RightArrow.

En anden løsning er at opsætte 2 individuelle præfikser, for eksempel C-bfor en lokal session, mens C-afor en ekstern. Med nedenstående konfiguration betyder det, at ved at trykke C-alokalt sendes standardpræfikset C-btil fjernsessionen. Fundet denne løsning her.

set -g prefix C-bbind-key -n C-a send-prefix

Men det føles virkelig som:

Den bedre løsning ville være at bruge den samme nøgletabel både på lokale og eksterne sessioner - ingen separate præfikser eller dobbeltklik på præfikset - og slå alle tastebindinger og præfikshåndtering fra i den ydre session, når du arbejder med den indre. Credits og dette Github-problem.

Så når jeg skal arbejde i den indre session, skal jeg bare trykke på F12og skifte OFFtilstand i den ydre session. Når det sker, viser den ydre session den OFFvisuelle indikator i statuslinjen og ændrer den visuelle styling af statuslinjen for yderligere at understrege, at sessionen er i OFF-tilstand.

Her er en Gist fra min fungerende tmux-konfiguration, som jeg lavede for nylig (kun relevante stykker er inkluderet):

Dybest set konfigurerer vi F12nøglebinding til rodtastetabellen. Når vi trykker på, indstiller vi præfikset til None, skifter den aktuelle offnøgletabel til, ændrer derefter stillinjen for statuslinjen og tvinger tmux til at opdatere statuslinjen. Et ekstra trin tages for at annullere den aktuelle rudekopieringstilstand, hvis den er til stede. Så snart vi skiftede til offtastaturet og slukkede for håndtering af præfikser, lytter den ydre session slet ikke efter nogen tastetryk. Alle tastetryk overføres til den indre session uden at blive opfanget af den ydre.

Det er alt sammen godt, men vi har på en eller anden måde brug for at komme tilbage og vende den ydre session tilbage til normal arbejdstilstand. Derfor opsætter vi en enkelt tastebinding F12i nøgletabellen off, som vender tilbage til effekten af ​​det første F12tastetryk.

Vi konfigurerer også en visuel indikator for statuslinjen, der viser, hvornår den aktuelle nøgletabel er off, og skjuler ellers.

For at afslutte, i betragtning af denne konfiguration, kan du konfigurere en enkelt lokal session med 1 vindue med 2 ruder, der indeholder indlejrede eksterne sessioner til forskellige værter (se billedet i begyndelsen af ​​indlægget).

Fjernspecifik konfiguration af sessioner

I det forrige eksempel bemærker du muligvis, at statuslinjen for den ydre session er placeret øverst, hvor den indre session har statuslinjen nederst. Det giver en god visuel skelnen og gør ikke statuslinjerne stablet oven på hinanden.

Men hvordan er det muligt at anvende forskellige betingelsesbaserede konfigurationer?

Nå, det er ret let. Vi kan registrere, om sessionen er ekstern eller lokal ved hjælp af SSH_CLIENTmiljøvariablen.

if-shell 'test -n "$SSH_CLIENT"' \ 'source-file ~/.tmux/tmux.remote.conf'

Og ~/.tmux/tmux.remote.conffilen indeholder den konfiguration, der kun anvendes til fjernsessionen. Der ændrer vi statuslinjens position og fjerner nogle widgets fra den (som ur og batteri), fordi de bare replikerer de samme widgets fra den lokale session.

Så det er det. Hvis du vil se alt dette i aktion, skal du tjekke mit tmux-config-lager.

Ressourcer og links

tmux / tmux: tmux kildekode - //github.com/tmux/tmux

Brug af Tmux eksternt inden for en lokal Tmux-session | Simply Ian - //simplyian.com/2014/03/29/using-tmux-remotely-within-a-local-tmux-session/

Indlejret tmux - //stahlke.org/dan/tmux-nested/

slå alle tastebindinger til / fra · Udgave # 237 · tmux / tmux - //github.com/tmux/tmux/issues/237

samoshkin / tmux-config: Tmux-konfiguration, der overbelaster din tmux for at opbygge hyggeligt og køligt terminalmiljø - //github.com/samoshkin/tmux-config