### /dev/null for graphics

Have the following ever happened to you?

You are trying to automate some data processing step. The step in question involves some complex, GUI-driven application, for which there is no source available or that source is a little to complex do dive in and extract the required functionality. As a happy coincidence, the application includes batch mode - but it still creates and displays the gui when running in batch mode (even when started with "nogui" option).

(in my particular situation, the app in question was Brainstorm, a collection of Matlab scripts. The original author is using Windows exclusively, thus he probably couldn't even imagine this scenario)

All of the above could be acceptable, but there is a slight problem - batch processing happens on a mainframe-style Linux server, without keyboard, display, or even X server running. Thus the application starts up, tries to create it's cosy GUI, obviously fails, and crashes hard.

When applications output some unneeded stuff to stdout, we have a universal solution - we send it to /dev/null. Turns out that Linux is flexible enough to do the similar thing with graphics!

We'll still need some sort of X server. In my case, I didn't have full control of the target machine, so I used what was already installed - Xvnc. Most probably, Xvfb (virtual framebuffer) will work better, since it was designed almost exactly for this use-case, but I wasn't able to install it.

The following small script showcases the usage - we launch X server, launch our program, wait for it to finish, and then kill X server.
#!/bin/bash
Xvnc :17 &
xvnc_pid=$! # Wait for X server to come online # Usually, it starts up much faster, but there are occassional stalls sleep 10 export DISPLAY=:17 matlab -nosplash -nodesktop -r "addpath('build/'); \ try;$1; exit(0); catch e; disp(e.message); disp(e.stack); exit(1); end"
exit_value=$? kill$xvnc_pid

exit \$exit_value