Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'A workaround for X11 sharing by multiple users' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A workaround for X11 sharing by multiple users
Authored by: hopthrisC on Feb 25, '04 04:38:29PM

BTW, when several Users start X11 (several times) on one Box, they actually don't share X. Quite the contrary!

If you really want to share one X11 display among several users, have a look at the xhost command (or turn off authentication in the X11 prefs...)



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: speir on Feb 25, '04 05:39:22PM

Thanks for all the information! I was hoping that the more experienced could tell me if I was going in the wrong direction.

1) Yes, we did find that the xterm $DISPLAY was automatically set, but after I posted. However we primarily use the Terminal program, so needed another solution.

2) Thanks for open-x11 - its the solution we were looking for. I did not know about this command. Works perfectly so my workaround is unnecessary (just have to set up a series of aliases since the lab is used to just typing the program name - was hoping for something more seamless).

3) No, we do not want to share one $DISPLAY (is this what you meant?). We wanted everyone to have a different $DISPLAY so they did not run into conflicts.

4) The workaround has been working very well for weeks (not a single problem), but I knew it wasn't ideal. Thanks again for the helpful comments.



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: hopthrisC on Feb 25, '04 06:11:49PM
2) Thanks for open-x11 - its the solution we were looking for. I did not know about this command. Works perfectly so my workaround is...
It's all in the FAQ: http://developer.apple.com/qa/qa2001/qa1232.html
...unnecessary...
At least you learned a lot about shell scripting and racing conditions ;)
...(just have to set up a series of aliases since the lab is used to just typing the program name - was hoping for something more seamless).
Ah! The joys of user education ;) Well, there is another hack that could help you with this. It's slightly ugly, but anyways: If you start X11.app from the Terminal (or from a script, which you can use as a Startup Item) like so:
  # /Applications/Utilities/X11.app/Contents/MacOS/X11 :$UID
It will use the user's (unique!) ID as display number. You then can set $DISPLAY to $UID in .tcshrc, .bashrc or even in ~/.MacOSX/environment.plist (which is the more general approach).

With this method the users can never get in each other's way and don't have to use open-x11. You only have to make sure that they don't start X11 on their own, or that they only start it via your script.

(With this method you can start several instances of X11.app at the same time, so don't be confused, if you see more then one X icon in the Dock!)

[ Reply to This | # ]

A workaround for X11 sharing by multiple users
Authored by: speir on Feb 25, '04 05:47:59PM

Forgot the clarification:

We wanted what Xterm does automatically, but in the Terminal.app - setting the $DISPLAY correctly for each user.

open-x11 is a good built in option, but not a complete solution. Is there a way to get the automatic $DISPLAY setting in Xterm to work in Terminal.app?



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: Ptitboul on Feb 27, '04 06:29:16AM

You asked "Is there a way to get the automatic $DISPLAY setting in Xterm to work in Terminal.app?"

Not really. The biggest problem is that you have to guess which X11 server you want to use. When xterm is launched from within X11, then the guess is that all applications lauched within this xterm should be displayed on that X11 server. But that may be a bad guess, and that is the reason why DISPLAY can be changed and why most X11 programs understand the -display flag.
If an X11 server is already running when Terminal.app is launched, then your technique is quite good, because the best guess you can make is to find an X11 server you are allowed to talk with. But you should at least check that DISPLAY was not set. If there is a previous value for DISPLAY (e.g. if the shell was lauched from within an ssh with X11 forwarding), then you should not change it.
However, if no X11 server is running when Terminal.app is launched, then your technique is not so good, because you make the hypothesis that the owner of this Terminal.app will be the next one to launch a new X11. I would rather not set DISPLAY, and ask that anyone that may need a X11 server launches it at login.
This is what I do. But, since launching X11 automatically launches an xterm, I find this annoying (I prefer Terminal.app). Therefore I deleted the line "xterm &" from /etc/X11/xinit/xinitrc



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: speir on Feb 27, '04 04:32:22PM

Thank you for the additional advice and very helpful information! Much appreciated.



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: jhegarty on Apr 10, '04 05:44:18AM

Interesting. I also prefer the Terminal, but don't always start X before starting the Terminal. It also seems like when I put the machine to sleep, X gets confused and I have to restart it when I wake the machine up (but I don't want to close and then reposition all my terminals!). I worked around the problem of having the Terminal start first by adding

[ ! "$DISPLAY" ] && export DISPLAY=:0.0

to my /etc/profile. (i.e.: if DISPLAY is not set when the Terminal starts, set it to :0.0, otherwise use the existing $DISPLAY) Of course, I'm really the only regular user on this machine, and definitely the only one using X locally. Setting the display like this doesn't seem to break ssh for remote logins, by the way. If I login to this machine remotely and X is already running locally, ssh still sets the display correctly for forwarding.

** Note: This was a Physicist's hack. Less messy than the Biologist's hack, but much more spur-of-the-moment and broken. ;)

Hmm .. it might be worthwhile to write a script that checks for the ownership of the .X##-lock files, and sets the display according to which one you own. That way X can still give you whatever display it wants to, and it should be trivial for a user to run a single command if they discover their X isn't set correctly (without worrying about exactly what it's supposed to be set to), right?

---
--[ you cannot consistenly judge this statement to be true ]--



[ Reply to This | # ]