Test of “display” capability in scripts

Petr Skoda wrote on Jan 12, 2010

Hi Mike,

I want to call from interactive cl script the "display" of image onto ds9 or ximtool. If the given graphic task is not running, I would like to either warn the user (and reject the display request) or run the ds9 automatically (after asking user). How can I reliably detect in the script that the given device for output is available or not ?

When not, the display complains :

ERROR: Cannot open device (node!imtool,,800,800)

But the test for access to the device does not work (and I do not know what kind of configuration of display is used)

So e.g.

print(access("node!imtool,,800,800"))

Does not show difference if running or not the ds9

Is there a reliable test finding the posiibility of communication with graphic device (from normal cl script ?).

Thanks

Petr Skoda

---

Mike Fitzpatrick wrote on Jan 12, 2010

There's no elegant way other than to try the display, catch an error and then recover. For example,

procedure zz ()

begin
        iferr {
            display ("dev$pix", 1, >& "dev$null")
        } then {
            printf ("Warning: No display server running, starting ds9..\n")
            printf ("!ds9 &\n") | cl()

            sleep (10)          # give ds9 a chance to startup

            # Try to display again
            display ("dev$pix", 1, >& "dev$null")
        }
end

---

Petr Skoda wrote on Jan 12, 2010

This solution works nicely for my purpose. In fact the trapping of errors is not explained in the basic scripting cookbook http://iraf.net/irafdocs/script/
which seems to be the only explanation how to write scripts in cl.

Thanks again!
Petr Skoda

---

Mike Fitzpatrick wrote on Jan 12, 2010

The script guide pre-dates the ECL error handling by quite a bit, for details see pkg$ecl/Notes.ecl

---

Petr Skoda wrote on Jan 12, 2010

Now I understand - the iferr check is a new feature of ecl.
In old IRAF versions (and in new ones with cl -old) this does not work and complains on syntax error.
So for this case (to be able to use old cl we still have on some older IRAF installations) I have found a workaround using the UNIX socket which the ds9 opens in a default way of instalation:

if (access("/tmp/.IMT1000")){
 #For practical case the running ds9 uses the UNIX socket on display 1
            display (imname, 1, fill+,  >& "dev$null")
         } else {
            printf ("Warning: No display server running, starting ds9..\n")
            printf ("!ds9 &\n") | cl()
            sleep (1)          # give ds9 a chance to startup
 # Try to display again
            display (imname, 1, fill+, >& "dev$null")
        }

This is not so elegant as the error catch but works (and the user should be warned that the ds9 should not be run in a non-standard way - with forced sockets or pipes or in IP mode )

Thanks anyway

---

Mike Fitzpatrick wrote on Jan 12, 2010

Two comments: The ".IMT1000" isn't fixed, it actually your userid appended to the string ".IMT" so it'll be different for different users. Second, the file isn't removed when the display server shuts down so it's possible the socket file can exist without having a valid display server.

---

Last post on Jan 12, 2010