I think that Paul is on the right track, but there may be more to it
than just the author citation.
Output needs to wait until G_parser() has been called.
After moving the fprintf()s it launches the GUI correctly for me from
the d.m menus.
I haven't tested it any further though.
If it is still breaking for you, then perhaps the code that figures out
the default values of dmin/dmax needs to be moved further down/abondoned
too???
There is an undocumented gui flag that Glynn has described but that I
can't find at the moment and I can't remember what it does. This might
help (I'm a big help, yes?).
sure, --ui.
lib/gis/parser.c:
* If first arg is "help" give a usage/syntax message */
if (strcmp(argv[1],"help") == 0 ||
strcmp(argv[1], "-help") == 0 ||
strcmp(argv[1], "--help") == 0)
{
G_usage();
return -1;
}
/* If first arg is "--interface-description" then print out
* a xml description of the task */
if (strcmp(argv[1],"--interface-description") == 0)
{
G_usage_xml();
return -1;
}
/* If first arg is "--html-description" then print out
* a xml description of the task */
if (strcmp(argv[1],"--html-description") == 0)
{
G_usage_html();
return -1;
}
/* If first arg is "--ui" then run G_gui() */
if (strcmp(argv[1],"--ui") == 0)
{
G_gui();
return -1;
}
/* If first arg is "--tcltk" then then generate
* code for tcltkgrass */
if (strcmp(argv[1],"--tcltk") == 0)
{
G_tcltk();
exit(0);
}
At the moment, I'll keep the menu entry calling v.surf.rst as it is
because I can't see changing it has any useful effects.
I don't think it's the menu's fault (but I guess it should be called
with the "execute" command like everything else unless there is a reason
not to do so). Either G_parser() needs to be more robust at handling
unexepected input or we must be strict about putting nothing unexpected
before the G_parser() call in each module.
Hamish