[GRASS-dev] Re: [GRASS-CVS] michael: grass6/gui/tcltk/gis.m mapcanvas.tcl, 1.52, 1.53

[Hamish]

Hamish:
> > I never get there as catch always returns 0 for me, even when
> > g.region failed.
> 
> This means that catch is not returning an error when g.region fails.

yes. This is what I am trying to figure out.

> > If I move "puts $input" before if {! $retval } above, that prints
> > "file8" or "file9", presumably the name of the $input stream that
> > gets() works on.
> > 
> 
> Yes, you are correct. Again, this suggests that g.region does not
> fail.

It fails.

catch{open "|cmd"} doesn't return the exit code of "|cmd", while
catch {exec "cmd"} does. The only thing that comes to mind is that in
the "open" case catch is catching the channel_id of the open{} function,
not the result of "|cmd":

open(n) "returns a channel identifier"
  http://www.astro.princeton.edu/~rhl/Tcl-Tk_docs/tcl/open.n.html

so the catch currently tests if a channel identifier could be opened ?


exec(n) returns:
  "If standard output has not been redirected then the exec command
returns the standard output from the last command in the pipeline. If
any of the commands in the pipeline exit abnormally or are killed or
suspended, then exec will return an error and the error message will
include the pipeline's output followed by error messages describing the
abnormal terminations; the errorCode variable will contain additional
information about the last abnormal termination encountered. If any of
the commands writes to its standard error file and that standard error
isn't redirected, then exec will return an error; the error message will
include the pipeline's standard output, followed by messages about
abnormal terminations (if any), followed by the standard error output."
  http://www.astro.princeton.edu/~rhl/Tcl-Tk_docs/tcl/exec.n.html


If we could get open{} to pipe stderr to the channel_id stream we might
be ok.


> Maybe the problem is that your failure is not the same as my
> failure. To simulate failure, I renamed g.region to g.region_x. See if
> this does fail on your system.

(too late now, will try tomorrow)

I was making it fail by renaming /usr/lib/libgdal.* to something else.

> If so, then we need to figure out where the gdal problem causes
> failure. There is another g.region statement in the code. So perhaps
> it is there.

No, it is the same place. I put lots of puts"" around it to see exactly
what was happening.


Hamish