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

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.


You can try with the xset command :

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

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
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 0;


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


if ./checkX; then
   echo "We are good to go!"
  • 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.

     # 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
     return $WORKS

  if x_works; then 

This appears to be working.

  • 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

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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