Re: X11 article, for review (take 2)
Re: X11 article, for review (take 2)
- Subject: Re: X11 article, for review (take 2)
- From: Randy Ford <email@hidden>
- Date: Mon, 31 Mar 2003 14:46:56 -0600
On Sunday, March 30, 2003, at 11:26 PM, Rich Morin wrote:
I have finished the second draft of my article on "X11 Tweaks"
for "Section 7", my column in MacTech Magazine. Please look
it over (http://www.cfcl.com/rdm/section7/2003.05.X11.2.pdf)
and let me know of any errors, omissions, etc.
From .pdf:
One alternative is to start up Terminal from the X11 start-up script.
Terminal will go into the
background on its own, so we donht need to use an ampersand:
open /Applications/Utilities/Terminal.app
My objection to this approach is that it requires me to run the X11
server all the time.
It really doesn't matter if X11.app is stopped and restarted, as long
as Terminal.app is kept running. All other Terminal instances created
from the app will inherit the environment with which Terminal.app was
started. Normally, X11.app will start with the same DISPLAY, even if
one is switching from one monitor to two, etc. (This isn't necessarily
the same with other X servers. With them, if one has two monitors, it
is likely that they will be configured with different DISPLAYs. Since
your article isn't addressing them, there is no need to discuss them.
A person set up that way will probably understand how to deal with
that.)
The important part is that DISPLAY gets set appropriately by the
X11.app. It assumes that the user wants programs that have both
text-based and X11 based display methods (such as emacs) will be
displayed using X11.
One problem with setting DISPLAY in startup scripts is that it will
cause many problems that are time consuming to troubleshoot. Here's an
instance:
The user is on a different machine on their network. They remotely log
in to the machine with DISPLAY hardcoded. If they didn't log in using
ssh -X, the DISPLAY won't have been set, so it gets hardcoded to the
incorrect value. (Ssh X tunneling isn't enabled by default on Mac OS
X, so users will likely try other methods.) We've seen that a lot on
this group. When the user tries to start an X11 program, it fails with
"Connection refused." The user spends hours trying to debug the system
where they are sitting. However, the X program is actually trying to
connect to the remote system, not the local one. If the DISPLAY had
not been hardcoded, the user would have received "DISPLAY not set," and
would have immediately understood the problem.
Through the years, I've seen many, many problems because people setting
their DISPLAY like you suggest. If a user never remotely logs in, they
may never have a problem. However, in today's environment, many people
will have some need to remotely log in. People will reinstall X11.app,
and even OS X to try to fix the problem before they get to a person, if
they ever do, who understands what is going on.
One alternative is to have a script (I've used x_d) to set the DISPLAY.
All it does is set the DISPLAY. It has to be sourced, not just
executes. In ksh and bash, use ". x_d". I guess you have to use
"source x_d" from a C shell.
What I see as the better alternative is for the user to xterm or some
other X11 terminal if they want to use X. Use Terminal.app if they
don't want to use X. If you search this group, you will find methods
of configuring xterm to look and feel much more like Terminal. This
includes the key strokes for things like cut and paste. The only thing
that I have found lacking is the ability to drag a file onto the xterm
and have the fully-qualified file name pasted into the xterm.
randy.
_______________________________________________
x11-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/x11-users
X11 for Mac OS X FAQ: http://developer.apple.com/qa/qa2001/qa1232.html
Report issues, request features, feedback: http://developer.apple.com/bugreporter
Do not post admin requests to the list. They will be ignored.