/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

Comments

Popular posts from this blog

How to create your own simple 3D render engine in pure Java

Solving quadruple dependency injection problem in Angular

Better CLI option parsing in Scala