Questo è un aggiornamento a Il PC in tasca, che ho pubblicato a luglio. Lì raccontavo come lasciare la workstation accesa a casa e raggiungerla da qualunque device con Tailscale, SSH e VS Code. Se non l'hai letto, quella è la base: qui do per scontato che l'accesso ci sia già.
Perché nel frattempo l'ho usato davvero, in viaggio, e ho scoperto due cose. La prima è che mancava un pezzo, e non un dettaglio. La seconda è che, sistemato quel pezzo, il setup è diventato molto più leggero di quanto avessi previsto.
Nel senso letterale, tra l'altro. Il mio kit da viaggio è diventato senza che me ne accorgessi un catalogo di cose che si piegano.
Il telefono si piega: è un Galaxy Z Fold 8, e aperto è un piccolo tablet. La tastiera si piega: è una ProtoArc pieghevole, chiusa sta nel palmo. Il mouse non si piega, ma è talmente piatto che tanto vale: un Pebble Mouse 2 M350s, preso come mouse da battaglia per lasciare l'MX Master a casa. E se ci aggiungo un monitor portatile, la scrivania intera si piega e sta in una tasca dello zaino.
C'è una sola cosa che non deve piegarsi: il lavoro. E per un po', invece, era proprio quella la parte fragile.
Nell'articolo di luglio avevo risolto il "come arrivo a casa": Tailscale per la rete, SSH solo con chiave per il terminale, un tunnel VS Code per l'editor nel browser. Funzionava. Da qualunque device raggiungevo la mia workstation e ci lavoravo sopra.
Poi ho iniziato a usarlo in movimento, e ho scoperto che accedere e lavorare non sono la stessa cosa.
Lancio un processo lungo dal telefono. Entro in galleria. La rete salta. Quando torna, non c'è più niente: il processo è morto a metà. Non è un bug, è come funziona SSH: il processo remoto è appeso alla connessione, e quando la connessione cade riceve un SIGHUP e se ne va, portandosi dietro tutto quello che stava facendo.
Passo dal wifi dell'hotel alla rete mobile: stessa storia, connessione nuova, sessione persa. Chiudo il telefono in tasca e Android decide di chiudere l'app: idem.
Il thin client funzionava benissimo finché stavo ferma. Ma io mi muovo, ed è tutto il punto.
Qui ho capito la distinzione che mi mancava, ed è la cosa più utile che ho imparato in questo giorni. Quando lavori da remoto ci sono tre cose diverse in ballo, e ognuna si rompe per conto suo:
Io avevo protetto solo… nessuna delle tre, a dire il vero. Avevo protetto l'accesso, che è un'altra cosa ancora.
Uso molto Claude Code, e lì l'equivoco era ancora più evidente: Claude Code salva la conversazione su disco, quindi con claude -c la riprendi sempre. Per un po' ho pensato che questo bastasse. Non basta: ti restituisce il discorso, non il lavoro. Se stava a metà di un turno, con un file modificato solo in parte e una build in corso, quella roba lì resta a metà. La conversazione è salva, il processo no.
Servivano due strumenti diversi per due problemi diversi. E si chiamano mosh e tmux.
mosh (mobile shell) sostituisce SSH per le sessioni interattive. Si autentica passando da SSH (quindi tutta la sicurezza che hai già configurato resta identica, chiavi comprese), poi sposta la sessione su un canale UDP suo.
Cosa cambia, in pratica:
Installazione, sul server:
sudo dnf install mosh # o apt/brew, a secondaCode language: PHP (php)E sul telefono, dentro Termux:
pkg install -y moshPoi ti colleghi con mosh workstation al posto di ssh workstation. Se hai un alias in ~/.ssh/config, mosh lo usa: fa fare la risoluzione a SSH e, se il nome non esiste nel DNS, si fa dare l'indirizzo dal server tramite $SSH_CONNECTION. Stampa un avviso che sembra un errore ma non lo è.
Sulla sicurezza, il dubbio che mi sono tolta subito. mosh usa UDP sulle porte 60000-61000, e la prima cosa che ho pensato è stata: ho appena finito di chiudere l'SSH sulla rete di casa, e adesso apro mille porte UDP? No. Il default di --bind-server è ssh, cioè mosh-server risponde solo dall'indirizzo da cui è arrivata la connessione SSH. Siccome SSH entra solo dalla VPN, mosh vive solo lì. L'ho verificato invece di fidarmi:
ss -lunp | grep mosh
# UNCONN 100.x.y.z:60001 users:(("mosh-server",...))Code language: PHP (php)Legato all'indirizzo della tailnet, non a 0.0.0.0. Nessuna regola di firewall aggiunta, nessuna porta aperta sul router.
Una cosa che mosh non fa: lo scrollback. mosh sincronizza solo lo schermo visibile, quindi non puoi scorrere indietro. È uno dei motivi per cui va in coppia con tmux, che lo scrollback ce l'ha.
La mia prima conclusione è stata: mosh sul telefono sì, sui portatili no. Il ragionamento sembrava solido. Sul wifi di casa la connessione non cade quasi mai, e ssh in cambio ti dà copia/incolla e scrollback nativi del terminale, che con mosh perdi. Perché pagare quel prezzo dove il problema non c'è?
Poi mi sono fatta una domanda che l'ha demolito in tre secondi: e se lavoro sul portatile in mobilità? Un portatile in treno, in tethering dal telefono o sul wifi di un bar vive esattamente le stesse cadute del cellulare. La mia regola presupponeva che i portatili stessero fermi a casa, cioè presupponeva l'esatto contrario di quello che tutto questo setup serve a fare.
La versione corretta è più corta e non ha eccezioni:
Non è quale device. È quale rete.
Quindi mosh si installa ovunque, e installarlo non obbliga a usarlo: i due modi convivono e scegli al momento della connessione. A casa ssh, in movimento mosh. Nessuna configurazione da cambiare, solo due comandi diversi.
Qualunque strada usi, il lavoro è al sicuro comunque: quello lo tiene tmux. mosh ti risparmia di ridigitare due comandi, non ti salva la sessione, quella è già salva.
mosh salva la connessione. Ma se il client muore davvero (Android chiude l'app, il telefono si spegne), serve che il lavoro stia da un'altra parte. Quella parte è tmux.
tmux gira sulla workstation e tiene i processi in una sessione che esiste indipendentemente da chi la sta guardando. Ti stacchi, la sessione continua. Ti riattacchi da un altro device, ritrovi lo stesso identico schermo.
Ed è qui che è arrivata la seconda scoperta, quella che non mi aspettavo: il sync. Non è solo persistenza. La sessione è una sola, quindi apro dal browser sul telefono, poi passo al laptop e sono nello stesso posto: stessi comandi in corso, stessa cronologia, stessi riquadri. Non "riprendo il lavoro", proprio continuo a guardare la stessa cosa da uno schermo diverso.
Prima avevo tre mondi separati che non si parlavano: il terminale del tunnel, quello di Termux, quello del laptop. Adesso sono tre finestre sulla stessa stanza.
E vale la pena esplicitare un corollario, perché la parola "sync" trae in inganno e me lo sono chiesto anch'io: non si sincronizza niente. Esiste una copia sola, sulla workstation, e sia l'editor che apri nel browser sia l'agente nel terminale lavorano su quel disco. Non c'è propagazione, non c'è ritardo, non c'è un passaggio che possa fallire a metà lasciandoti due versioni diverse: l'unica domanda che resta non è "quando arriva la modifica", ma "l'editor ha riletto il file?".
Nella pratica quotidiana tmux si riduce a un comando:
tmux new -A -s main # attacca a "main", la crea se non c'èCode language: PHP (php)Il -A è il dettaglio che lo rende usabile: non devi mai ricordarti in che stato avevi lasciato le cose. Ci metti un alias sopra e non ci pensi più.
E li unisci così, in un comando solo che collega e attacca:
alias lg='mosh workstation -- tmux new -A -s main'Code language: JavaScript (javascript)Questa merita di essere raccontata perché è il tipo di errore che sembra funzionare per settimane, e poi ti frega di notte.
A luglio avevo messo il tunnel VS Code come servizio systemd, con un restart automatico alle 04:30 (i tunnel Microsoft tendono ad andare zombie dopo un po'). Ottima idea allora, e resta ottima.
Poi ho notato una cosa: i terminali che apri nel tunnel sopravvivono già alla chiusura del browser, perché vivono dentro il servizio, non nella pagina. Bello. Ma vivono dentro quel servizio. E alle 04:30 quel servizio si riavvia, portandosi via tutto quello che ha dentro.
A quel punto mi sono chiesta: e se lancio tmux da lì?
# il cgroup del server tmux appena avviato
cat /proc/<pid>/cgroup
# → .../app.slice/<il cgroup di chi lo ha lanciato>Code language: HTML, XML (xml)Ho verificato, ed è così: il server tmux eredita il cgroup di chi lo avvia. Se la prima volta lo lancio dal terminale del tunnel, tmux nasce dentro il servizio del tunnel, e alle 04:30 muore insieme a lui. Avrei messo la mia rete di sicurezza dentro esattamente la cosa da cui doveva proteggermi, e me ne sarei accorta una mattina, senza capire perché.
La soluzione è dare a tmux un servizio suo, così ha un cgroup indipendente:
# ~/.config/systemd/user/tmux.service
[Unit]
Description=Server tmux - sessione persistente
Documentation=man:tmux(1)
[Service]
Type=forking
ExecStart=/usr/bin/tmux new-session -d -s main
ExecStop=/usr/bin/tmux kill-server
Restart=always
RestartSec=5
[Install]
WantedBy=default.targetCode language: PHP (php)systemctl --user enable --now tmux.service
loginctl enable-linger $USER # se non l'hai già fatto: parte al boot senza loginCode language: PHP (php)Due regali in più: la sessione esiste da subito dopo il boot (quindi dopo un riavvio non devi ricordarti niente, t attacca e via), e il restart notturno del tunnel diventa completamente innocuo.
La morale, che vale ben oltre tmux: quando metti qualcosa in un servizio, guarda dentro cosa lo stai mettendo. Un processo lanciato da dentro un servizio systemd appartiene a quel servizio, anche se sembra staccato.
tmux si comanda con un tasto "prefisso", di default Ctrl+B. Ho passato più tempo del previsto su questa scelta, e ne è valsa la pena.
Ctrl+B, il default, è occupato da Claude Code, che lo usa per mandare un task in background. E Claude Code è la cosa che gira dentro tmux tutti i giorni. Scartato.Ctrl+Space, l'alternativa a cui pensavo, sembra perfetto: nessuno lo usa. Peccato che su Android venga intercettato dal sistema per cambiare metodo di input, quindi a Termux non arriva mai. Sarebbe saltato proprio col telefono e la tastiera fisica, cioè nello scenario per cui stavo facendo tutto questo. Scartato.Ctrl+A, il classico di chi viene da GNU screen, costa l'inizio-riga nella shell, che uso di continuo.Ctrl+Q è libero dappertutto. 🚀unbind C-b
set -g prefix C-q
bind C-q send-prefix # doppio Ctrl+Q manda comunque un Ctrl+Q letteraleCode language: JavaScript (javascript)Il punto generale: se il tuo setup deve funzionare anche da mobile, il mobile non è il caso limite da sistemare dopo. È il vincolo più stretto, e conviene partire da lì.
Se dentro tmux ci fai girare Claude Code (o qualunque TUI moderna), servono tre righe che non sono opzionali:
set -g allow-passthrough on
set -s extended-keys on
set -as terminal-features 'xterm*:extkeys'Code language: JavaScript (javascript)Senza allow-passthrough, tmux si mangia notifiche e barre di progresso e non arrivano mai al terminale vero. Senza le due righe sui tasti estesi, tmux non distingue Shift+Invio da Invio, quindi quando vai a capo in un prompt lungo lo invii invece di andare a capo. Una tortura silenziosa.
Aggiungo il true color, che sennò i colori vengono slavati:
set -g default-terminal "tmux-256color"
set -as terminal-features ',xterm*:RGB'Code language: PHP (php)E lo scrollback generoso, visto che con mosh è l'unico che hai:
set -g history-limit 50000Code language: JavaScript (javascript)Ed eccoci al pezzo Fold.
Il telefono aperto è già uno schermo su cui si legge codice. Con la tastiera pieghevole agganciata diventa una postazione vera, e le due cose insieme stanno in una tasca. Se poi in viaggio trovo uno schermo (la TV della casa vacanze, o un monitor portatile nello zaino), collego solo il telefono e ho una scrivania completa.
Nella stessa tasca c'è un terzo pezzo, ed è quello a cui sono più affezionata: un 8BitDo Micro, un pad bluetooth grande quanto una scatoletta di cerini. Ce l'ho per giocare ai retrogame. Ma ha un dettaglio che lo rende molto più interessante di così: sotto ha un interruttore con tre posizioni, S, D e K, e la K è modalità tastiera. In quella posizione tutti e sedici gli input diventano tasti mappabili, che configuri dall'app 8BitDo Ultimate.
Il che vuol dire che un pad da retrogaming può diventare un pannello di scorciatoie fisiche.
Con tmux la cosa si incastra da sola: le combinazioni che uso di più sono tutte prefisso più un tasto, e sono esattamente il genere di cose scomode da fare su una tastiera piccola. Un pad che ti sta nel palmo e fa staccare la sessione o saltare da un riquadro all'altro con un pollice è, nel mio setup, tutto tranne che un giocattolo.
Un dettaglio pratico che non trovi quasi mai scritto: come si preme un "prefisso più tasto" su una tastiera che non ha il Ctrl.
Termux risolve con una riga di tasti extra sopra la tastiera software, dove CTRL funziona da modificatore agganciato: lo tocchi, resta armato, e si applica al tasto che tocchi dopo. Quindi una scorciatoia che sul portatile è un accordo simultaneo, sul telefono diventa una sequenza di tocchi:
CTRL → q → c (nuova finestra)
CTRL → q → w (elenco di tutto quello che ho aperto)
CTRL → q → d (stacco e me ne vado)Detto così sembra macchinoso, ma alla mano diventa naturale in mezza giornata, ed è il motivo per cui più sopra dicevo che un pad fisico con la modalità tastiera si incastra bene: quelle sequenze sono esattamente il genere di cosa che un tasto dedicato fa sparire.
La parte che mi diverte è il rapporto fra i pesi. Da una parte una workstation con una GPU seria, che resta a casa al sicuro e fa tutto il lavoro. Dall'altra qualche etto di roba pieghevole che non calcola niente: mostra soltanto.
E qui c'è il punto che lega tutto l'articolo. Il client può essere così leggero solo perché non contiene niente. Non ci sono file, non ci sono processi, non c'è stato: c'è una vista su una sessione che vive altrove. Il che vuol dire che il device è sacrificabile. Si scarica, si spegne, Android lo chiude, lo perdo in aeroporto: cambio schermo, riattacco e sono esattamente dove ero.
Prima di mosh e tmux non era vero. Prima, il device leggero era anche fragile, perché il lavoro dipendeva da lui: se moriva lui, moriva la sessione. La leggerezza era un rischio. Adesso è solo leggerezza.
Fin qui ho parlato di terminale. Ma se il telefono deve fare da postazione vera serve anche un editor, e qui la risposta ovvia è anche quella fragile.
L'ovvia è VS Code nel browser, via tunnel. Funziona, ha l'albero dei file, i diff, tutto al posto giusto. Però è l'unico pezzo del setup che vive dentro una scheda del browser, e Android le schede in background le congela: cambi app, torni, e deve riconnettersi. Non perdi niente, perché il lavoro sta in tmux, ma è l'unica cosa che ti fa aspettare.
Due accorgimenti banali aiutano: installala come app dal menu del browser, così diventa una finestra sua nello switcher invece di una scheda, e togli le restrizioni batteria al browser che la ospita.
Il terzo non è banale e non lo trovi scritto: attenzione a quale browser scegli. Io uso Brave tutti i giorni, ma i suoi Shields possono rompere il tunnel, che è interamente WebSocket. E dentro una PWA non c'è la barra degli indirizzi, quindi il pannello degli Shields non lo raggiungi: le impostazioni sono per-sito e vanno messe prima, da una scheda normale. Ho preferito tenere Brave per la navigazione e mettere la PWA su un browser diverso, così non indebolisco la configurazione privacy su un sito che uso ogni giorno.
Nessuno dei tre risolve davvero, però, ed è giusto dirlo: la sospensione la decide il sistema operativo, non il browser. Riduci l'attrito, non lo elimini.
Riduci l'attrito, non lo elimini.
La stabile è l'editor che nel terminale ci vive già. Neovim dentro tmux eredita in blocco tutto quello che abbiamo costruito: niente WebSocket, niente schede, niente freezer di sistema. Se Android chiude l'app, l'editor continua a casa con il file aperto e il cursore dov'era.
Una finestra con l'editor, una con l'agente, entrambe nella cartella del progetto:
lg
cd ~/progetti/mio-progetto
nvim .
# Ctrl+Q c -> finestra nuova, gia' nella stessa cartella
claudeCode language: PHP (php)Un'insidia da conoscere se lavori così. Con un agente AI e un editor aperti sugli stessi file, l'editor deve accorgersi quando i file cambiano da sotto. Altrimenti succede questo: l'agente modifica foo.py, tu hai ancora la versione vecchia a schermo, salvi, e sovrascrivi il suo lavoro senza nessun avviso. In Neovim si copre con autoread più un checktime su FocusGained e BufEnter. E c'è un incastro carino: perché l'editor sappia quando torni sulla finestra, dentro tmux serve focus-events on. Un'opzione messa per un motivo si rivela necessaria per un altro.
Il limite onesto: i notebook. Farli girare nell'editor del terminale si può, un plugin apre un kernel vero ed esegue le celle. Ma vedere un notebook è un'altra cosa da eseguirlo, e una vista a celle con il markdown impaginato e gli output disposti, in un terminale, semplicemente non esiste. Attenzione ai convertitori tipo jupytext: non sono visualizzatori, e alcuni, se configurati male, ti azzerano gli output salvati al primo salvataggio. Se invece ti serve solo eseguire un notebook lungo, lo lanci con nbconvert o papermill dentro tmux, ti stacchi, e torni a leggere il risultato quando ha finito.
Quindi non è "l'editor del terminale batte il browser". È che ognuno copre quello per cui è fatto:
| Cosa stai facendo | Con cosa | Perché |
|---|---|---|
| Codice, refactor, agenti | Neovim + tmux | massima stabilità, immune a tutto il resto dell'articolo |
| Notebook con grafici | browser via tunnel | i grafici nel terminale non ci arrivano |
| Sfogliare, diff visivi | browser via tunnel | più comodo, e se si riconnette pazienza |
Se cerchi in giro, trovi pagine e pagine di gente che combatte contro Android che chiude Termux in background: termux-wake-lock, ottimizzazione batteria su "senza restrizioni", max_phantom_processes da alzare via adb. È una battaglia che si ricombatte a ogni versione di Android e che, leggendo le issue aperte, si perde comunque.
Con questa architettura non la combatti proprio, perché è la domanda sbagliata. tmux non gira sul telefono, gira sulla workstation. Se Android chiude Termux, muore il client: il server mosh e la sessione tmux continuano tranquillamente a casa, e alla riapertura riprendi.
Non ho attivato nessun wake lock, non ho toccato nessuna impostazione sviluppatore. Il problema è sparito spostando il lavoro, non blindando il telefono.
Il locale. mosh pretende un locale UTF-8 sul client, e Termux gira su Bionic, la libc di Android, che supporta solo C/POSIX e poco altro. Il mio it_IT.UTF-8 lì non esiste: setlocale fallisce in silenzio, il locale ricade su US-ASCII e mosh si rifiuta di partire. Si risolve con una riga:
echo 'export LANG=en_US.UTF-8' >> ~/.bashrcCode language: PHP (php)Effetto collaterale da mettere in conto: mosh propaga il locale al server, quindi le sessioni aperte dal telefono arrivano in inglese.
Il mouse che ti toglie la tastiera. Avevo acceso set -g mouse on, che sulla carta è perfetto per il mobile: scorri col dito. Nella pratica, con il mouse acceso tmux intercetta il tocco, quindi il tap sullo schermo non arriva più a Termux e la tastiera software non si apre. Ti ritrovi dentro una sessione perfettamente funzionante, senza poter scrivere niente.
L'ho lasciato spento di default, con un interruttore per accenderlo quando serve davvero:
set -g mouse off
bind m set -g mouse \; display "mouse #{?mouse,on,off}"Code language: JavaScript (javascript)Se ti succede e sei senza tastiera, dalla workstation tmux set -g mouse off sblocca tutti i client all'istante.
Il costo nascosto: i server che si accumulano. Ogni volta che un client VS Code si collega installa sulla macchina remota un server della sua identica versione, circa 700 MB, e quando il client si aggiorna il vecchio resta lì per sempre. Nel mio caso è doppio, perché il tunnel e Remote-SSH tengono i loro server in cartelle diverse: quando sono andata a guardare c'erano nove versioni per 6,8 GB, di cui due in uso, e lato tunnel se ne depositava una nuova ogni quattro o cinque giorni.
C'è un comando ufficiale che dovrebbe risolvere, e la sua documentazione dice testualmente "Delete all servers which are currently not running". L'ho lanciato con quattro versioni ferme: ha risposto "Successfully removed all unused servers" e non ne ha cancellata nemmeno una. Ho provato a dimostrarmi che sbagliavo io, perché è più probabile che l'errore sia mio che di un comando ufficiale: quattro ipotesi diverse su cosa considerasse "in uso", quattro smentite, e nessuna traccia del problema nell'issue tracker. Non so perché non funzioni, e preferisco scriverlo così invece di offrire una spiegazione elegante e inventata.
Quello che so è che un messaggio di successo che descrive un'operazione mai avvenuta è, come genere di bugia, peggio di un errore: se avessi creduto all'output avrei archiviato il problema come risolto, e me lo sarei ritrovato più grosso fra un mese senza sospettare di niente. Ho finito per scrivermi uno script di venti righe che cancella una versione solo se nessun processo ha quel percorso aperto e non è la più recente, agganciato al restart notturno che già avevo. Recuperati 4,7 GB.
Le cose che si rompono in silenzio. Mentre mettevo su tutto questo ho scoperto che nel mio editor l'evidenziazione della sintassi via treesitter era spenta da mesi. Un aggiornamento di sistema aveva portato avanti l'editor, i plugin erano rimasti fermi a gennaio, e la mia configurazione parlava una lingua che la versione nuova ignorava senza dire niente: i parser erano lì sul disco, solo che nessuno li agganciava più. Non me n'ero accorta perché l'editor ripiegava sull'evidenziazione classica, che somiglia abbastanza da non insospettire.
È la stessa forma esatta del terminale del tunnel che moriva ogni notte alle 04:30: rotto, ma invisibile, perché quello che restava assomigliava al funzionamento. Sono i guasti peggiori, quelli che non cerchi perché non hanno sintomi.
La morale operativa è banale e la scrivo soprattutto per me: certe cose vanno verificate con un comando, non a occhio. Un contatore che non salta un colpo mentre stacchi la rete, un
ssche ti dice su quale indirizzo sei davvero in ascolto, una riga che ti risponde vero o falso. Buona parte del lavoro raccontato in questo articolo è stata guardare i numeri invece dello schermo, e quasi ogni volta i numeri dicevano qualcosa che lo schermo non diceva.
La tabella onesta, limiti compresi:
| Cade la rete | Il client muore | Riavvio della workstation | |
|---|---|---|---|
ssh + comando | ❌ | ❌ | ❌ |
| Terminale nel tunnel del browser | ✅ | ✅ | ❌ |
| mosh + tmux | ✅ | ✅ | ❌ |
Nessuno dei due sopravvive a un riavvio della macchina di casa: lì i processi se ne vanno comunque. Con il servizio systemd la sessione torna su da sola, ma vuota. Per la conversazione di un agente AI resta il suo resume, che a quel punto è esattamente lo strumento giusto: ognuno protegge il suo pezzo.
Se un giorno volessi ripristinare anche i layout dopo un riavvio, esistono tmux-resurrect e tmux-continuum. Per ora non mi servono: i riavvii sono rari e programmati.
Per entrare, due alias e nient'altro:
lg # dal telefono: mosh si collega E attacca alla sessione, in un colpo
t # da qualunque altro terminale: attacca alla stessa sessione
# (alias di: tmux new -A -s main)Code language: PHP (php)Poi tutto passa dal prefisso, che nel mio caso è Ctrl+Q. Su tastiera fisica è un accordo, su Termux è la sequenza di tocchi vista sopra.
| Tasti | Cosa fa |
|---|---|
Ctrl+Q d | Detach: esci e lasci tutto vivo |
Ctrl+Q w | Cosa ho aperto? Elenco navigabile di sessioni, finestre e riquadri con anteprima |
Ctrl+Q c | Nuova finestra |
Ctrl+Q n / p | Finestra successiva / precedente |
Ctrl+Q 1…9 | Vai alla finestra N |
Ctrl+Q x | Chiudi il riquadro dove sei |
Ctrl+Q & | Chiudi la finestra intera, chiede conferma |
Ctrl+Q , | Dai un nome alla finestra, così w diventa leggibile |
Ctrl+Q | / - | Split verticale / orizzontale |
Ctrl+Q h j k l | Sposta il focus fra i riquadri |
Ctrl+Q z | Zoom sul riquadro (utile su schermo piccolo) |
Ctrl+Q [ | Scorri indietro nello scrollback di tmux, q per uscire. Vale nei riquadri con una shell: dentro Claude Code lo scrollback è suo, si usano PgUp / PgDn |
Ctrl+Q ? | Tutte le scorciatoie |
Quello da imparare per primo, se ne devi imparare uno solo, è Ctrl+Q w. Con una sessione che vive per giorni ti serve continuamente sapere cosa ci hai lasciato dentro, e la barra di stato in basso da sola non basta quando le finestre diventano parecchie.
Fare pulizia, che con una sessione longeva serve più di quanto pensi. Dalla shell puoi agire su una finestra precisa senza andarci sopra:
tmux kill-window -t main:2 # chiude la finestra 2 e basta
tmux kill-window -a # chiude tutte tranne quella dove sei
tmux ls # cosa c'e' in giroCode language: PHP (php)Per ricominciare da capo non usare tmux kill-server: fai ripartire il servizio.
systemctl --user restart tmux.serviceCode language: CSS (css)Il risultato è lo stesso, ma la sessione si ricrea dentro il servizio, quindi nel cgroup protetto. Uccidendo il server a mano rischi che il prossimo avvio nasca dove capita, e ti ritrovi con il problema della Parte 3 che pensavi di aver risolto. Per lo stesso motivo la unit va scritta con Restart=always e non on-failure: kill-server esce con codice zero, che per systemd è un successo, quindi con on-failure il servizio resterebbe semplicemente spento.
Due note dall'uso quotidiano:
window-size latest), e su Termux, quando si apre la tastiera software, al terminale restano tredici righe. Se lasci il telefono attaccato e poi torni al monitor grande, ti trovi una finestrella in alto a sinistra e tutto il resto riempito di puntini: è tmux che segnala lo spazio in eccesso, non un guasto. Si sistema appena digiti, oppure con tmux a -d, che attacca staccando gli altri. Ma l'abitudine giusta è Ctrl+Q d prima di rimettere il telefono in tasca.A luglio avevo risposto a "come raggiungo casa". Questo aggiornamento risponde a una domanda che allora non sapevo nemmeno di dover fare: come faccio a non perdere quello che sto facendo.
E la risposta si è rivelata più interessante della domanda, perché non era un problema di connessione ma di dove vive il lavoro. Finché viveva appeso alla connessione, ogni galleria era un rischio. Spostandolo dentro una sessione che non dipende da nessun client, il resto è diventato accessorio: quale device uso, se cade la rete, se Android chiude l'app, se il telefono si scarica.
Il che è, alla fine, quello che mi serviva per farci stare tutto in tasca. Il telefono si piega, la tastiera si piega, lo zaino si chiude. La sessione resta dritta a casa e mi aspetta.
Tutto si piega, tranne quello che conta.
Strumenti
Approfondimenti citati
I miei articoli
Oggi è il secondo giorno dal mio rientro. La mia testa continua a correre, a pensare, a tentare di mettere a terra tutte le idee e gli stimoli accumulati in questi giorni. Dall'altro lato continua a rivivere momenti, sorrisi, difficoltà affrontate, sensazioni scaturite dal parlare con altre persone, dal trovarsi davanti degli occhi che si […]
Sono lieta di presentare NutriCHOice, un progetto innovativo sviluppato come culmine del percorso formativo del Bootcamp AI di Edgemony. Questo assistente culinario intelligente utilizza l'approccio "Generate then Fix" per creare ricette personalizzate che rispettano obiettivi nutrizionali specifici, con particolare attenzione ai carboidrati (CHO). Un ringraziamento speciale Questo progetto è stato reso possibile grazie al supporto […]