Re: The meaning(s) of $DISPLAY (was Re: Explanation of X implementations)
Re: The meaning(s) of $DISPLAY (was Re: Explanation of X implementations)
- Subject: Re: The meaning(s) of $DISPLAY (was Re: Explanation of X implementations)
- From: "Andrew J. Hesford" <email@hidden>
- Date: Sat, 17 Nov 2007 02:20:03 -0600
On Nov 17, 2007, at 1:18 AM, Ambrose Li wrote:
On 17/11/2007, Eric Gouriou <email@hidden> wrote:
On Nov 16, 2007, at 8:50 PM, Ambrose Li wrote:
[...]
$DISPLAY being set means that X is _available_, not that the
user desires to get X clients started or that contacting
the X server is a 0-cost operation. Indeed it can already
be pretty expensive to contact an already running server,
for example when operating over long latency connections.
Thanks to launchd, X is always running on Leopard. It's just
very, very good at consuming no resources as long as it has
no clients. That's similar to traditional network services
started via xinetd, "the ssh server" is available as soon as
it is configured, whether an instance of the sshd executable
is currently running or not.
I would think that this is backwards. Thanks to launchd, X is
always *available*. Certainly when you first log in (unless
you have it set to run in System Preferences) it is *not*
running. On the other hand, on a non-Leopard system, if $DISPLAY
is set, the worst thing that can happen is that it is set to
a crashed server so any X command errors out, but any script
can then trap the error and conclude that X is not really
available. (Ok, this is not the worst; the worst could be
$DISPLAY pointing to another still-running server that is at
somewhere you don't expect. But this is still nowhere near
expectedly *starting up* an X server when all you want is to
check for its existence, for example.)
The point you're missing is that the user doesn't always want to use
the X server just because it is available (via launchd) or already
running (started either by the user or launchd). Checking $DISPLAY to
determine the course of action circumvents the user, and that's not
good. I'll give you a good example: when I log into remote machines
and launch vim, it causes launchd to start X11, because vim was
compiled with X11 support, and it is querying the display about
something. This happens even though vim doesn't use X... it is purely
textual. To avoid having my X server automatically start when I start
vim, I have to explicitly tell vim not to use X. This is annoying and
wrong.
You'll think this is a case in your favor, but it isn't. Because the
issue isn't that launchd is starting the server... it's that vim is
checking for servers. Even if I already have X open for a legitimate
reason (let's say I'm running an xterm), vim has no business looking
for servers, because I didn't tell it to. Yes, it was compiled with
support for X11. But until I launch it as gvim (which opens up a
graphical window), it should stay the hell away from my X server.
I want X11 (or actually launchd) waiting around for me, so X11 can
start when I want it to... which means when I launch an application
that requires X. But applications are broken that automatically assume
they can fool with my X server just because $DISPLAY is set. Software
should never try to guess what the user's intentions are. If they
aren't obvious, either ask, or take no action.
The beauty of launchd is that you no longer have to check for the
server's existence. There's no distinction, because it will be there
if you need it. When you start an application that legitimately
requires X, it's obvious you want X running, so launchd will run it.
If you have shell scripts that check for $DISPLAY to make decisions,
I'll bet you can rethink the problem and you'll find a better solution.
The bottom line is this: unless a script or program REQUIRES X, it
should never check to see if it is running in the presence of an X
server, because it shouldn't be using X, unless the user explicitly
says so. And whether the script or program was instructed to use X, or
it simply requires X, the user will be expecting X to start, so it
should do so automatically.
And if you disagree, you can always disable the launch agent.
Cheers,
Andrew
--
Andrew J. Hesford <email@hidden>
Department of Electrical and Computer Engineering
University of Illinois at Urbana-Champaign
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden