In a previous job we wanted to run regression tests without a zillion
windows popping up, so we ended up
running each command in a separate x server. -- I know -- that sounds
excessive, but a X Server is really relatively light duty and this
avoids dealing with issues of the server hanging or dying for some
strange reason. We used a heavily modified version of vncserver to do
the job. Basically we renamed the script runXcmd and it took the command
as an argument, defaulted all the normal vncserver options, launched the
server, ran the command, waited for it to finish, and then shut down the
server. Each command got a nice fresh server, always setup the same way.
Here is a script that will do esentially the same thing - with less
elegance and a little less error recovery. It assumes that you have
installed tightvnc, which has some advantages over vnc, but not for this
application - other than it is available as a package for some
distributions. vnc the original package, is downloadable, now called
'real vnc' and almost free. But tight vnc does the job.
You just say 'runCommand some_command_or_script'
The one thing missing, is I didn't add a abort timer to prevent hanging
the script by running a command (line xterm)
that doesn't terminate. hoping it isn't too mangled by the mail system:
--------runCommand---------
#!/bin/ksh
output=`vncserver 2>&1 |grep "desktop is"` #launch X server
disp=${output#*desktop is } #strip off string before display setting
dispnum=${disp#*:} # strip off host:
# now run the command with DISPLAY set to alternate X server
export DISPLAY=$disp
"$@"
sleep 1 # let everything settle
p=`ps -eo pid,args |grep Xtightvnc |grep :$dispnum"` # find X server
pid=${p#+( )}
pid=${pid%% *}
if [[ $pid != "" ]] ; then
kill $pid # and kill it
else
echo "oops, I didn't find the Xtightvnc server"
fi
---------------------------------
occasionally killing any old Xtightvnc servers might be useful -
assuming your not using tightvncserver for other things.
a Simple 'killall Xtightvnc' does that. If you were nice, you would
want to just kill Xtightvnc processes that were say, more than a week
old, but that would take a bit more scripting. In our siutuation, we
had people that used vnc to launch remote desktops that might be around
forever.
steve
Tim Wescott wrote:
> This is a medium-bizarre question, but an answer would be of great help
> to me. I've actually asked it on the Scilab list, but if there's not a
> Scilab answer to it, I'd be happy with a Linux one:
>
> I have some papers that I maintain on my web site, for example:
> http://wescottdesign.com/articles/Sampling/sampling.pdf.
>
> These are authored in lyx, with some figures generated with Scilab. The
> site is archived as software, and built using a makefile, including the
> pdf files. Rather than keeping the figures as generated graphics files,
> I keep the Scilab files and generate the figures as needed.
>
> To generate a figure, make runs its generating script from a shell, e.g.
>
> scilab -nw -nb -e
>
"execstr(['errcatch(-1,''kill'')';'scf';'exec(''motor-PD-friction.sce'');';'quit'])"
>
> Scilab thinks that it's an interactive environment, so when the script
> makes a figure, Scilab opens the window on top of whatever is running,
> draws it, then closes it. Since I have several papers on the site (and
> its growing), this means that I can't leave the make running in the
> background and get work done, because I'm constantly getting windows
> created in my face.
>
> It's kind of like trying to read in the same room as a cat, except that
> Scilab figures are not warm and fuzzy, and they do not purr.
>
> Scilab does have a "don't use graphics" mode, but if you try to make a
> graph in that mode it bombs.
>
> Is there some way of running a command from a shell that gives the
> command a working X environment (so that it can make the figure), but
> hides that environment from me (so that I can keep designing a circuit,
> answering my mail, or whatever it is that engineers do)?
>
> Thanks in advance.
>
_______________________________________________
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
