[GRASS-dev] GRASS startup window patches

[Glynn Clements]

Paul Kelly wrote:

> As we saw in the discussions about g.region and gis.m, using the Tcl catch 
> commands on GRASS commands isn't generally a good idea

On the contrary, most exec (and "open |...") commands *should* use
catch so that errors (either real errors or Tcl complaining about
stderr) aren't fatal.

> as Tcl falsely 
> assumes a command that writes to stderr is issuing an error. This applies 
> to g.proj too. If partially-specified datum information is passed to 
> g.proj, it WILL try to interactively prompt the user for complete 
> information. This is done by printing to stderr and looking for an input 
> on stdin.(The Tcl catch command will treat this as an error.) There are 
> also circumstances where g.proj will issue a warning (but still proceed to 
> create the location OK), and again this writes to stderr and the catch 
> command will erroneously assume there is an error.

No, it's exec which treats it as an error; the catch command catches
the exception which exec throws so that it doesn't terminate the
program.

> I think, until we can work out some way of always passing fully specified 
> datum information to g.proj, that when g.proj is used for location set-up 
> we should run it in a pop-up terminal Window. So if it does choose to 
> prompt the user it (while kludgy and archaic-looking) will actually work. 

What is the problem with simply removing the "interactive" parameter
from GPJ_{osr,wkt}_to_grass()?

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