[GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal

[Michael Barton]

Glynn,

Thanks for looking at this. Run_panel is indeed based directly on your run
procedure from a year or so back (part of the execute, run, spawn, and term
procedures you did to resolve problems in the pull-down menu system).

Given what you say...

1) Should run_panel be eval exec -- $cmd >@ /dev/null  ?
2) Should this be the case for the run procedure too?
3) Display commands don't really need to show progress because it is
visually indicated, so sending output to /dev/null shouldn't be a problem.
And I can do that easily. However, this is where all error messages would go
too. TclTk gives error feedback, but it is usually not as easy to decipher
as GRASS errors. So, if a display command fails because (for example) you
forgot to indicate the name of a map (pressing the columns button in the
vector panel), the result is not obvious. So until a way is worked out to
redirect ALL command output to the GIS Manager window, there won't be any
error output from GIS Manager commands except for TclTk error output.

I struggled over gui.tcl for many hours last weekend. I understand what it
is doing pretty much, but it is considerably more complicated than needed in
this case and I was unable to extract or create the code to redirect all
output to the window at the bottom of the GIS Manager.

So, at the moment, the alternatives I can do are:
1) keep it the way it is, with progress and errors sent to the GRASS
terminal--the way it has been for the past year or so--or
2) redirect GIS Manager output to /dev/null--keeping the GIS Manager clean
of all but CLI input and output and having TclTk handle all errors.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Fri, 21 Oct 2005 14:54:05 +0100
> To: Michael Barton <michael.barton at asu.edu>, Paolo Cavallini via RT
> <grass-bugs at intevation.de>, <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes
> the Grass terminal
> 
> 
> Glynn Clements wrote:
> 
>>> If you think it is better then to reopen this bug number for a different
>>> issue, I guess that is your call. It just seemed to me that we solved the
>>> first issue. Now that it's solved, another issue has become apparent. This
>>> is often the case. I just want to make sure that the appropriate people take
>>> a look at this. It's not d.m per se, but any commands (or possibly d.rast).
>>> You'd get the same result if you did this from the command line.
>> 
>> Yes, but if the commands are invoked by d.m, d.m should arguably be
>> redirecting stdout and stderr to its internal log window.
> 
> To elaborate, the issue appears to be that run_panel is redirecting
> the program's stdout/stderr to d.m's stdout/stderr rather than
> consuming them itself or discarding them.
> 
> proc run_panel {cmd} {
> global outtext
> 
> eval exec -- $cmd >@ stdout 2>@ stderr
> set str $cmd
> $outtext insert end "$cmd\n"
> $outtext yview end
> 
> update idletasks
> }
> 
> The same issue appears to apply to the run procedure.
> 
> Both should ideally be behaving like run_cmd from gui.tcl, i.e. using
> open rather than exec, and using prnout (or an equivalent) to consume
> the output.
> 
> Alternatively, a quick fix would be to redirect to /dev/null instead
> of stdout/stderr.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>