PERL Beginners - How to detect present X-Server

Author

How to detect present X-Server

Matthias Kraatz

2004-12-16, 3:56 am

Hi everybody -

is there a way to make a perl program find out whether a valid X-Server
is running?
I.e. $ENV{DISPLAY} is not a dummy address, if set.

Thanks,
Matthias

Jonathan Paton

2004-12-16, 8:56 am

> is there a way to make a perl program find out whether a
> valid X-Server is running?
> I.e. $ENV{DISPLAY} is not a dummy address, if set.

Not in a useful way.

I have a headless (no monitor) Linux server, and a Windows
desktop with a X win server. If I forget to run the X server it
doesn't mean that DISPLAY contains a dummy address...

If a script made a guess at whether I wanted X functionality
(say for installation), then it could get it wrong. That would
be most annoying.

If a script wants to know if it can use the X server (or if one
exists), then it should go ahead and try. If the toolkit returns
an error then you know you don't have one.

In the situation you want to use X if available, terminal
otherwise, wouldn't it be better just to use an option?

More detail, better answers!

Jonathan Paton

--
#!perl
$J=' 'x25 ;for (qq< 1+10 9+14 5-10 50-9 7+13 2-18 6+13
17+6 02+1 2-10 00+4 00+8 3-13 3+12 01-5 2-10 01+1 03+4
00+4 00+8 1-21 01+1 00+5 01-7 >=~/ \S\S \S\S /gx) {m/(
\d+) (.+) /x,, vec$ J,$p +=$2 ,8,= $c+= +$1} warn $J,,

Matthias Kraatz

2004-12-16, 3:59 pm

Jonathan -

thanks for the input. Actually I wanted to provide more details but I
thought there would be a simple and standard solution for it (that I
hadn't found.)

Anyway, I am working on a project for interfacing a simulation
software, creating input files, processing output, scripting variations
of parameters for huge numbers of batch simulations and all that.
For certain subprocesses (imaging, text editing, etc.) it would be
useful to know whether X functionality is there or not. Example: do I
launch vi or xedit, should I even try to display an image, start OpenDX
or not, and so on.
I thought about an option, works for me. But since a group of people is
using the tool, I want to make it as simple as possible.
What I have noticed - when started without X support - X applications
sometimes just sit there as idle processes, not quitting with an error
'cannot open display etc...'. They accumulate and waste resources.

So maybe I should change my strategy - from highest-functionality to
working-simple-but-by-default, the latter with explicit options to step up.

I thought that maybe a function/module would exist, returning true if X
supported.

Thanks for your reply and ideas,
Matthias

Jonathan Paton wrote:

>
>Not in a useful way.
>
>I have a headless (no monitor) Linux server, and a Windows
>desktop with a X win server. If I forget to run the X server it
>doesn't mean that DISPLAY contains a dummy address...
>
>If a script made a guess at whether I wanted X functionality
>(say for installation), then it could get it wrong. That would
>be most annoying.
>
>If a script wants to know if it can use the X server (or if one
>exists), then it should go ahead and try. If the toolkit returns
>an error then you know you don't have one.
>
>In the situation you want to use X if available, terminal
>otherwise, wouldn't it be better just to use an option?
>
>More detail, better answers!
>
>Jonathan Paton
>
>
>

Lawrence Statton

2004-12-16, 3:59 pm

> > is there a way to make a perl program find out whether a
>
> In the situation you want to use X if available, terminal
> otherwise, wouldn't it be better just to use an option?
>

Well -- from a human-issues standpoint, requiring the user to decide
that which could be automatic is (in my arrogant opinion) the worst
solution :)

It is one of the misfeature's of emacs that always makes me grumble --
if I'm at a place where my $DISPLAY variable is set, but for one
reason or another X cannot work, it burns my cookies that I have to
remember to emacs -nw ... that it can't fall-back on its own.

The most common (and near daily for me) occurance of this is: I'm
sitting at my xterminal at home, and ssh to my colo machine (as me).
I then su to some other EUID - suddenly I have a valid DISPLAY
identifier, but that server cannot be contacted for lack of
permissions.

I'm certain that a tiny 'attempt to connect to the server on
$ENV{DISPLAY} and do nothing' program can be written.

Now, having an OPTION (in that I may safely opt out without ill
effect) that allows me to SUPPRESS that automatic check is a GOOD
thing. But requiring me to know that my $DISPLAY is set but
unreachable is a stone in my shoe.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Lawrence Statton - lawrenabae@abaluon.abaom s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
sort them into the correct order.

Lawrence Statton

2004-12-16, 3:59 pm

>
> I'm certain that a tiny 'attempt to connect to the server on
$ENV{DISPLAY} and do nothing' program can be written.
>

File this under "ugly but works"

............................... BEGIN PERL PROGRAM ......................
#!/usr/bin/perl
use strict;
use warnings;
my $message = `xlsfonts -fn NOTBLOODLYLIKELYTOOCCUR 2>&1 `;
unless ( $message =~ /pattern.*unmatched/ ) {
print "No X for you!" ;
} else {
print "It's not called X-Windows. It is a window system called `X'\n";
}
................................ END PERL PROGRAM .......................

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Lawrence Statton - lawrenabae@abaluon.abaom s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
sort them into the correct order.

Sponsored Links