11

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.

3 Answers 3

11

You can try with the xset command :

if [[ ! $(xset -q) ]]; then
   # the X server is not reachable
else
   # the X server is reachable
fi
3
2

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
5
  • 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. Aug 26, 2009 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 :( Aug 26, 2009 at 19:29
  • That is the first X program I have ever written in C, so, not sure if it is entirely reliable :-) Aug 26, 2009 at 19:52
  • And not the most portable thing ;-) Aug 26, 2009 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 :) Aug 26, 2009 at 20:02
1

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.

2
  • 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. Aug 26, 2009 at 19:45
  • the '1' there is stderr redirect for bash ;) , not a xdpyinfo param :) Aug 26, 2009 at 19:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .