Grsync e unison-gui, se eseguiti in ssh, si aprono sulla macchina remota

Se digito, da terminale,

ssh -X [email protected] grsync

oppure

ssh -X [email protected]

grsync

la finestra del programma si apre sul computer remoto, anziché su quello da cui sto digitando i comandi.

Stessa cosa per il programma unison-gui, mentre gli altri programmi si aprono correttamente sulla macchina locale.

Volevo capire se c’è qualcosa che potrei fare (a parte, ovviamente, utilizzare le controparti a riga di comando), perché se mi collego in ssh è perché in quel momento non ho accesso alla macchina, altrimenti il comando lo eseguirei direttamente sulla macchina remota.

Trovo il comportamento dei due programmi paradossale ed illogico, e spero che esista un workaround per risolvere.

Mia domanda a Gemini:

Quando non c’è una sessione grafica remota (per esempio, quando non ho fatto il login sul computer remoto in gdm) unison-gui e grsync, eseguiti da una sessione in ssh, funzionano, aprendo la finestra sul computer locale. Invece, quando c’è una sessione grafica remota attiva, viene aperta la finestra lì, il che non ha senso per un comando dato in ssh. In ogni caso, l’output di echo $DISPLAY è sempre localhost:10.0, anche quando il programma apre la finestra da remoto.

Risposta di Gemini:

Perché si comporta così?
Quando sul server remoto c’è una sessione utente attiva (gestita tramite GDM/GNOME), viene istanziata una variabile chiamata XDG_RUNTIME_DIR.
Molte applicazioni recenti e librerie grafiche cercano prima di tutto di parlare con il demone di sessione D-Bus dell’utente o con il socket Wayland/X11 locale memorizzato in quella cartella, ignorando parzialmente la variabile $DISPLAY passata dal tunnel SSH.
Se non c’è una sessione attiva (GDM disconnesso): Quella cartella/ambiente non esiste, l’applicazione è costretta a usare il meccanismo standard DISPLAY=localhost:10.0, e si apre in locale.
Se c’è una sessione attiva: L’applicazione intercetta i socket locali del server tramite D-Bus ed “evade” il tunnel SSH, aprendosi sullo schermo remoto.
Come risolvere il problema da remoto (senza disconnettere la GUI)
Se vuoi usare unison-gui da remoto via SSH senza dover spegnere o disconnettere la sessione grafica dell’utente dall’altro computer, puoi forzarlo a ignorare l’ambiente desktop del server pulendo temporaneamente le variabili d’ambiente per quel comando.
Prova a lanciare l’applicazione in questo modo nella tua sessione SSH:

env -u XDG_RUNTIME_DIR -u DBUS_SESSION_BUS_ADDRESS unison-gui

Soluzione definitiva
Puoi usare lo stesso identico trucco anche per grsync. Da terminale SSH ti basterà lanciare:

env -u XDG_RUNTIME_DIR -u DBUS_SESSION_BUS_ADDRESS grsync

Come rendere la cosa comoda (creare degli Alias)
Andare a scrivere ogni volta l’intero comando env -u … è scomodo. Puoi creare degli alias temporanei o permanenti nel file di configurazione della tua shell sul computer remoto (es. nel file ~/.bashrc di Fedora sul server).
Apri il file con un editor di testo sul server remoto:

nano ~/.bashrc

Aggiungi queste righe in fondo al file:

alias unison-gui=’env -u XDG_RUNTIME_DIR -u DBUS_SESSION_BUS_ADDRESS unison-gui’
alias grsync=’env -u XDG_RUNTIME_DIR -u DBUS_SESSION_BUS_ADDRESS grsync’