[GRASS5] d.m and d.mon fail after cvs update

[Glynn Clements]

Michael Barton wrote:

> I had this problem, but fixed it in a different way and so need to ask about
> it.
> 
> I had a strange monitorcap (with double xmon definitions) file that came
> with the most recent (13 February) Mac binary from Lorenzo Moretti. Perhaps
> this is/was being generated during Mac compiles as this seems to be reported
> by Mac folks.
> 
> When I fixed the monitorcap file AND commented out the following line...
> 
>                 #set env(MONITOR_OVERRIDE) "gism"
> 
> in the procedure that creates the output PPM and then creates a TclTk image
> from thePPM, it worked.
> 
> With the fix you mention below, should I try uncommenting the
> MONITOR_OVERRIDE statement?

The use of MONITOR_OVERRIDE and the fix which I mentioned are
unrelated.

Without the version.h.in fix, monitor drivers will simply segfault at
startup. the fix is necessary to be able to use monitors.

MONITOR_OVERRIDE allows applications to redirect d.* commands to a
specific monitor without using "d.mon select=..." (which will
interfere with the user's use of monitors).

gis.m should always be using MONITOR_OVERRIDE rather than
"d.mon select=gism".

BTW, It is now be possible for gis.m (and similar programs, e.g. 
d.out.png) to avoid the use of monitorcap altogether. You can start
monitors directly with e.g. (shell syntax):

	$GISBASE/driver/PNG foo '' ''
	MONITOR_OVERRIDE=foo d.vect fields
	d.mon stop=foo
	# or:
	# $GISBASE/etc/mon.stop foo

without the monitor name having to appear in the monitorcap file.

This doesn't work when using FIFOs, although I don't know if anyone
still uses FIFOs, and I'm inclined to remove FIFO support altogether
unless someone can provide a good reason why it needs to stay.

-- 
Glynn Clements <glynn at gclements.plus.com>