On Dec 15, 2007, at 7:40 PM, John Koren wrote: Only if the X server is already running. If you let DISPLAY stay as /
tmp/launch-blah/:0, then that works whether X11 is running or not.
I guess you did not read my next sentence in which I said t hat it appears that the special socket seems to be superfluous. I did not say that the socket does not work. I was just asking what is its purpose. It seems like a quick hack.
Others have already answered this question in this thread, but I'll give you my answer, because I am the one that made this change.
The real answer to this question is "The socket name has the format that it does because it was the easiest way to make this work." It required no code changes whatsoever to launchd, and only 20 or so lines of code change to Xtrans.
It may help if you see how this is done; if you look at /System/Library/LaunchAgents/org.x.X11.plist, you'll see
<key>Sockets</key> <dict> <key>:0</key> <dict> <key>SecureSocketWithKey</key> <string>DISPLAY</string> </dict> </dict>
The man page for 'launchd.plist' explains what this means:
Sockets <dictionary of dictionaries... OR dictionary of array of dictionaries...> This optional key is used to specify launch on demand sockets that can be used to let launchd know when to run the job. The job must check-in to get a copy of the file descriptors using APIs outlined in launch(3). The keys of the top level Sockets dictionary can be anything. [...] SockPathName <string> This optional key implies SockFamily is set to "Unix". It specifies the path to connect(2) or bind(2) to.
SecureSocketWithKey <string> This optional key is a variant of SockPathName. Instead of binding to a known path, a securely generated socket is created and the path is assigned to the environment variable that is inherited by all jobs spawned by launchd.
Therefore, I was able to use SecureSocketWithKey -- a functionality provided by launchd for anybody who wants to use it -- to get launchd to automatically create a socket for me, inside of a securely-created directory, named ':0', and then it would automatically set the environment variable 'DISPLAY' to that pathname.
If you'd like to see another part of OS X that uses this functionality, take a look at /System/Library/LaunchAgents/org.openbsd.ssh-agent.plist.
This also neatly sidesteps the issue of deciding what socket to use if /tmp/.X11-unix/X0 already exists.
What sort of problems does the new scheme cause for you? I am a little
worried by your email from earlier:
> I like to bundle my applications but when I set the display to say :
> 0 (eg. rxvt -display :0) then the launcher does not start X11 or it
> pops up an extra xterm, depending if it is a script or a bundle. Of
> course I can rewrite all my scripts and bundles so that they do not
> contain display :0 however it would be nice if the launcher was
> smarter about it so I would not have to remember all these special
> Mac-only details.
You shouldn't be setting DISPLAY at all, nor should your scripts/
bundles be explicitly launching X11. So I don't think I see how there
are any "special Mac-only details" to remember.
I had to rewrite my shell scripts and bundles containing DISPLAY settings to accommodate the new system. I work interchangeably on Mac and Solaris systems and it is a big plus if I can use the same shell scripts on both systems. That's what I meant by Mac-only details.
If you are hard-coding the value 'DISPLAY=:0' on any multi-user system, you are already committing a gross hack by making two bad assumptions:
1) that the X server is already running (this is a reasonable assumption on other platforms, because often you start programs from within X11. In that case, why do you need to set DISPLAY at all?)
2) that you are the only person running X on your machine, and that someone else will not be using DISPLAY :0.
-- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
|