[GRASS5] d.m and d.mon fail after cvs update
glynn at gclements.plus.com
Thu Feb 23 09:59:19 EST 2006
Michael Barton wrote:
> I had this problem, but fixed it in a different way and so need to ask about
> 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
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
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
# $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>
More information about the grass-dev