Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

This is a bit of a middle-ground between programming and server-admin, but this seems ultimately the most relevant place for it.

I'm looking for a way to determine if the variable '$DISPLAY' is advertising an XServer we can actually connect to, that is, if all the authentication and whatnot is in place to permit further things to execute.

I'm ideally looking for something shell-end tool that returns true/false, which can be used in a build-script to determine if the other tests in it ( which I don't control ) should be run or not.

The tests at present simply check for the env variable "$DISPLAY", and if it's there, will try to connect, and when the connection doesn't work, the tests assume failure of the test, not simply the display is not connectible.

I just need to be able to do

if [[ ! can_connect_to_X ]] ; then 
    unset DISPLAY
fi

In order to stop these tests having severe mental problems.

In an ideal situation, the tool required to do this should come provided with the X Client libraries itself, so as not to incur special dependencies, and to be able to assume if the utility is not there we can't connect to any display.

share|improve this question

3 Answers 3

up vote 3 down vote accepted

You can try with the xset command :

if [[ ! $(xset -q) ]]; then
   # the X server is not reachable
else
   # the X server is reachable
fi
share|improve this answer
    
Although I ended up using it in a more complex way, xset appears to be more likely installed than xdpyinfo. –  Kent Fredric Aug 26 '09 at 21:04
    

I am guessing there is a better solution. But you can always just use a small tool like xclock and check the exit status.

if [[ ! xclock ]]; then
  exit 1
fi
pkill xclock

But man, that is ugly :-)

Less Hacky, put the following in checkX.c:

#include <X11/Xlib.h>
#include <stdio.h>

int main() 
{
    Display *display;
    if( ! (display=XOpenDisplay(NULL) ) ) {
    	return(1);
    }
    return 0;
}

Then:

gcc -lX11 checkX.c -o checkX
chmod +x checkX

Lastly:

if ./checkX; then
   echo "We are good to go!"
fi
share|improve this answer
    
Yeah, that is the first thing I considered, but I wanted something that didn't visually create a window :/. I even considered doing xclock& and then killing it. –  Kent Fredric Aug 26 '09 at 19:28
    
xclock -geometry 1x1 is about the best I can do to eliminate visual intrusion :/, but it also allocates a task-space on the task bar :( –  Kent Fredric Aug 26 '09 at 19:29
    
That is the first X program I have ever written in C, so, not sure if it is entirely reliable :-) –  Kyle Brandt Aug 26 '09 at 19:52
    
And not the most portable thing ;-) –  Kyle Brandt Aug 26 '09 at 19:56
    
That is pretty awesomely handy, just unfortunately, my constraints are somewhat tighter. Truth to be told, I'm writing an ebuild(gentoo), so I have to virtually do /everything/ in shell, and assume that apps will be there before hand and I cant just add binary blobs ahead of time to 3rd party apps :) –  Kent Fredric Aug 26 '09 at 20:02

Heres a possible WayToDoIt, not sure how good it is though.

  x_works(){
     # If there is no xdpyinfo
     # Bash will return 127
     # If X cant connect, it returns 1
     # If X can connect, it returns 0
     xdpyinfo 1>/dev/null 2>&1
     WORKS="$?"
     return $WORKS
  }

  if x_works; then 
   ...

This appears to be working.

share|improve this answer
    
On my Fedora 11 machine I'm getting: $ xdpyinfo 1 usage: xdpyinfo [options] Anyway, I think that it sounds like a good idea to use the xdpyinfo program. –  Cristian Ciupitu Aug 26 '09 at 19:45
    
the '1' there is stderr redirect for bash ;) , not a xdpyinfo param :) –  Kent Fredric Aug 26 '09 at 19:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.