On Dec 17, 2007 8:07 AM, Jeremy Huddleston <email@hidden> wrote:
On Dec 17, 2007, at 02:06, John Koren wrote:
> Jeremy, > > I do not have any applications launched by .xinitrc. I did more > experimentation and I think I can now explain the basis for the odd
> behaviour. I believe it stems from the fact that X11.app does not > like DISPLAY to be set to :0.
Right, if DISPLAY=0, then X11.app will try launching xterm on that display. Since it can't (there's not one running), it will try
starting the server itself rather than letting launchd do it.
> Here are three similar scripts that react quite differently. It is > assumed that the environment variable DISPLAY is not set prior to
> executing the scripts. > > 1) > #! /bin/sh > DISPLAY=:0; export DISPLAY > xterm & > /usr/bin/osascript -e 'tell application "/Applications/Utilities/ > X11.app
" to activate'
> In this case no xterms end up being launched. Because DISPLAY set > to :0, the xterm from the script and (presumably) the xterm in > X11.app time out with an error "xterm Xt error: Can't open display: :
> 0". After that X11 actually starts up and I can launch other > applications normally. The applications inherit DISPLAY=:0.
Exactly. This is bad. Don't set DISPLAY.
> > 2) > #! /bin/sh > xterm -display :0 & > /usr/bin/osascript -e 'tell application "/Applications/Utilities/ > X11.app" to activate' > > In this case two xterms are launched. The script xterm probably just
> sits because of its display :0 flag, however, because the DISPLAY > environment variable is not set, the following line launches > X11.app and its own xterm. Once X11 is running the initial xterm
> also launches and we end up with two xterms.
You're getting the :0 one showing up eventually as a bug. You *shouldn't* be able to see that xterm, but you do as a bug. You're in the lucky state where
X11.app actually takes DISPLAY=:0 and don't accidently send the xterm to another user's X11.
> 3) > #! /bin/sh > xterm & > /usr/bin/osascript -e 'tell application "/Applications/Utilities/
> X11.app" to activate' > > This script follows the latest rules and indeed produces the desired > result of launching one xterm. The xterm call goes through launchd/ > X11.app as expected. The following osascript brings
X11.app to the > front otherwise, when the script is bundled, the xterm would launch > behind the Finder window.
What version of X11 are you using? If X11 is not running, it starts in the foreground with
I was not clear enough. When X11 starts up, it is brought to the front. The osascript call is there for the case when X11 is already running.
I bundle my Xterm script using Platypus and put the scripts icon to the Finder toolbar. In Tiger, when X11 was running, launching the script
from the toolbar would launch xterm in front of the Finder window. In Leopard, the xterm is launches behind.
> I believe this unusual behaviour could be circumvented if lauchd/ > X11.app would accept display settings of the form :0, localhost:0.
Hopefully this will clear up your misunderstanding of $DISPLAY. You don't use $DISPLAY to tell the server what to do. xinit sets $DISPLAY to tell clients spawned from it how to connect to the server that it
spawned. In our case, launchd's plist and X11.app act as xinit. We're moving stuff out of X11.app into xinit for the next release.
DISPLAY=:0 This is shorthand for DISPLAY=unix:0 which means to use the /tmp/.X11-
unix/X0 socket to connect to the server
DISPLAY=localhost:0 This tells the X client to connect to the X server over TCP/IP at 127.0.0.1 port 6000
This tells the X client to connect to the X server using the /tmp/ launchd-xxxxx/:0 socket
I think I now fully understand the interplay between these sockets in the examples I gave above. Thanks.
I have one question. How is it that a plain 'xterm' call prompts launchd to start X11 while xterm with DISPLAY set to :0 does not?
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden