Aggiorna
Lo sviluppatore Jeremy Huddleston Sequoia ha annunciato ieri che questo problema è stato risolto in < a href="http://xquartz.macosforge.org/downloads/SL/XQuartz-2.7.8_beta2.dmg"> XQuartz 2.7.8_beta2 :
XQuartz 2.7.8_beta2 is available for download.
You can see http://xquartz.macosforge.org/trac/wiki/X112.7.8 for a
full set of changes, but most noteworth ones are:
1) xauth now correctly parses the Yosemite launchd $DISPLAY socket path
2) libGL has been updated to Mesa 10.4.4
3) Various exploits were fixed in xorg-server, freetype, and libpng
4) A bug preventing automatic updates in some cases has been fixed
Il bug report è chiuso e contrassegnato come fisso:
Se non puoi (o non vuoi) installare la versione beta, puoi comunque utilizzare la soluzione che spiego di seguito.
RISPOSTA
Analisi
(scorri verso il basso per la sezione soluzione alternativa)
Il mio primo pensiero è stato "la variabile DISPLAY
è sbagliata". Ma non lo è.
Come risulta, su OS X 10.10 Yosemite (e torna a 10.8 Mountain Lion ) il La variabile DISPLAY
memorizza un percorso socket launchd
:
/private/tmp/<socket name>
anziché il familiare nome visualizzato:
hostname:displaynumber.screennumber
(Ho aggiunto alcune informazioni sul formato hostname:displaynumber.screennumber
alla fine di questa risposta.)
Questo significa che xauth
deve sapere come affrontare questa incarnazione speciale della variabile DISPLAY
, e come a Mavericks, ma il socket usato in Yosemite ha un percorso diverso (più precisamente: /private/tmp/com.apple.launchd.XXXX
anziché /private/tmp/launch-XXXX
) e xauth
interruzioni.
Questo bug è stato segnalato al team XQuartz il 18 novembre 2014 (3 mesi fa) ( link ):
The xauth program has code in both gethost.c and parsedpy.c to look
for $DISPLAY names that start with "/tmp/launch", and to treat that as
a local socket. However, the location seems to have changed, $DISPLAY
now starts with "/private/tmp/com.apple.launchd", so the code that is
looking for /tmp/launch doesn't catch it. (...)
Secondo la descrizione del bug deve essere risolto in XQuartz 2.7.8, che è in ritardo di 4 mesi (vedi la pagina del roadmap del progetto su link ).
La patch che risolve il problema è stata commessa il 31 dicembre 2014 sul progetto freedesktop.org ( link ):
diff --git a/parsedpy.c b/parsedpy.c
index c591b77..7365224 100644
--- a/parsedpy.c
+++ b/parsedpy.c
@@ -42,6 +42,9 @@ in this Software without prior written authorization from The Open Group.
#include <X11/Xauth.h> /* for FamilyLocal */
#include <X11/Xmu/SysUtil.h>
+#include <sys/stat.h>
+#include <sys/syslimits.h>
+
#if defined(UNIXCONN) || defined(LOCALCONN)
#define UNIX_CONNECTION "unix"
#define UNIX_CONNECTION_LENGTH 4
@@ -158,8 +161,32 @@ parse_displayname (const char *displayname,
if (!host) return False;
- if(strncmp (host, "/tmp/launch", 11) == 0) {
- family = FamilyLocal;
+ {
+ /*
+ * If using launchd socket, remove the screen number from the end
+ * of $DISPLAY and check if it is a path to a socket.
+ */
+ char path[PATH_MAX];
+ struct stat sbuf;
(...)
Quindi è solo una questione di tempo prima che questa patch arrivi alla prossima versione di XQuartz.
Soluzione
(testato su OS X 10.10.2 Yosemite.)
Add:
alias ssh="ln -fs $(echo $DISPLAY | sed 's:\(/private/tmp/com\.apple\.launchd\.[^/]*\)/.*::') $(echo $DISPLAY | sed 's:/private/tmp/com\.apple\.launchd\.\([^/]*\)/.*:/private/tmp/launch-:'); ssh"
a ~/.bashrc
e avvia una nuova finestra di Terminale o la origina ( . ~/.bashrc
) nella tua sessione Terminale corrente.
Questo alias innanzitutto associa il percorso socket a /private/tmp/launch-XXX
(ad esempio ln -fs /private/tmp/com.apple.launchd.GuewxwWwKS /private/tmp/launch-GuewxwWwKS
) e quindi avvia ssh
:
Pericuriosi,tradizionalmente,ilnomevisualizzatodelserverXhaavutoquestoformato(damanX
suUbuntu):IlnomevisualizzatodelserverXhaquestoformato:
hostname:displaynumber.screennumber
dove:
hostnameThehostnamespecifiesthenameofthemachinetowhichthedisplayisphysicallyconnected.Ifthehostnameisnotgiven,themostefficientwayofcommunicatingtoaserveronthesamemachinewillbeused.displaynumberThephrase"display" is usually used to refer to a collection of monitors that
share a common set of input devices (keyboard, mouse, tablet, etc.). Most worksta‐
tions tend to only have one display. Larger, multi-user systems, however, fre‐
quently have several displays so that more than one person can be doing graphics
work at once. To avoid confusion, each display on a machine is assigned a display
number (beginning at 0) when the X server for that display is started. The display
number must always be given in a display name.
screennumber
Some displays share their input devices among two or more monitors. These may be
configured as a single logical screen, which allows windows to move across screens,
or as individual screens, each with their own set of windows. If configured such
that each monitor has its own set of windows, each screen is assigned a screen num‐
ber (beginning at 0) when the X server for that display is started. If the screen
number is not given, screen 0 will be used.