displaying xterm apps from remote linux system ?

The difference is probably that the DISPLAY variable in the Terminal window wasn't set. In the xterm, of course it is, because the xterm needed it set in order to find the display. If you care to try it, do

export DISPLAY="localhost:0.0"

in Terminal before doing the ssh -X.

I struggled with a similar issue from a different perspective. I set the DISPLAY variable in my .bash_profile so that I didn't have to do it every time I started terminal.app. Of course, this overrode the automagic configuration of DISPLAY on a remote system when I tried to tunnel X11 through ssh. Jeff Hubbach's solution, to have the script set DISPLAY only if null, is one way around this.

By accident today I discovered another way. I was downloading openoffice.org 2.0 and they pointed to this ADC page: http://developer.apple.com/darwin/runningx11.html. There are benefits of using terminal.app to start X clients that come from the full integration of terminal.app into OSX. So I stripped out the setting of DISPLAY from my .bash_profile, and I just used the "open-x11" script referred to on the ADC page to start X clients automagically from terminal.app.

Ironically, this works locally but STILL doesn't set the DISPLAY variable on the local system. Thus, if you use "ssh -Y" in terminal.app to connect to a remote machine, the DISPLAY variable on the remote machine isn't set properly, either. It seems that Jeff Hubbach's solution is the most straightforward by being universal.

ssh -X yourname@the.linux.computer

or

ssh -Y yourname@the.linux.computer

then it all gets set up automatically. Just type

xclock &

at the prompt and it should open on your mac

Bill's provided the best answer, of course; ssh -X has the advantage that your X11 traffic is encrypted as it goes over the network.

But if you're curious, xhost should be present in /usr/X11R6/bin. In addition to "xhost +"ing, you'd need to poke a hole in your firewall (System Preferences > Sharing > Firewall) for X11 traffic (port 6000).

I tried 'ssh -X userid@IPaddress of the linux box
export DISPLAY='IPaddressofpowermac'😮
xclock

No, you shouldn't have done the export DISPLAY= line.

SSH X11 forwarding is a wonderful thing. It encrypts all X11 traffic, which is nice. But even nicer, it sets up all the necessary DISPLAY variables for you so you don't have to worry about it. On the server you're SSHing to, the DISPLAY should look something like this: localhost:10.0

Do the following, step by step:

1) open X11 on the mac
2) open an xterm (or terminal, doesn't matter as long as DISPLAY gets set up, but it's easier from the xterm).
3) echo $DISPLAY (you should get 😮.0)
4) open xeyes locally, make sure that works
5) ssh -Y username@serverip
6) echo $DISPLAY (you should get localhost:10.0)
7) open xeyes on the server, it should pop up on your mac.

You don't have to worry about DISPLAY (other than ensuring it's set locally before you ssh to the server), you don't have to worry about xhost, and you don't have to worry about the firewall (because everything is tunnelled (sp?) through SSH on port 22).

Simple. Much much simpler, and more secure, than manually configuring all that stuff.

Keith,

As Karl already said, that's because Terminal doesn't set the DISPLAY environment variable (which is why I had you echo it, and try to open a local xeyes, first).

I have the following in my .bashrc (which is sourced in my .bash_profile), which sets up the DISPLAY env variable if it isn't already set. This allows me to, assuming X11 is open, open X11 apps from Terminal and ssh -Y from Terminal.

.bashrc (sourced in .bash_profile)

if [ "${DISPLAY}" == "" ]; then
export DISPLAY=:0.0
fi

Yeah, for some reason it only works if the DISPLAY variable is first set (to whatever) locally. I think it is some sort of security precaution. Those of us who set this variable for Terminal.app from a login script tend to forget this. (It gets set automatically in xterm.)

Hey guys
I am having a similar problem but the above solutiong does not work for me. I am trying to open an xterm app but get this message:

[ ~]$ nedit: the current locale is utf8 (en_US.UTF-8)
nedit: changed locale to non-utf8 (en_US)
NEdit: Can't open display

I am trying to open nedit from a remote unix server but it won't seem to work. Any help would be appreciated.