Details Ticket 3709


Comment | Reply | Open


Serial Number 3709
Subject d.m - commands output pollutes the Grass terminal
Area grass6
Queue grass
Requestors werchowyna@epf.pl
Owner mbarton
Status resolved
Last User Contact Fri Jun 23 21:54:14 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Fri Jun 23 21:54:14 2006 (2 yr ago)
Created Tue Oct 4 11:47:27 2005 (3 yr ago)

Transaction History Ticket 3709


Tue, Oct 4 2005 11:47:27    Request created by guest  
Subject: d.m - commands output pollutes the Grass terminal

Platform: GNU/Linux/i386
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs 07.09.2005

Grass terminal is flooded with output from the d.m commands. Please pipe this
output to a separate terminal or to a particular d.m window. It really hampers
the user using both d.m and Grass CLI.

Cheers,
Maciek
Wed, Oct 19 2005 13:12:17    Owner changed to mbarton by mneteler  
Wed, Oct 19 2005 13:12:58    Mail sent by mneteler  
Michael,

since you nicely managed the xterm/v.info problem (thanks!),
do you now see a chance to also redirect the output?

Markus
Wed, Oct 19 2005 17:02:50    Status changed to resolved by mbarton  
Wed, Oct 19 2005 17:31:37    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 19 Oct 2005 08:03:49 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
In-reply-to <20051019111217.540AE1006C3@lists.intevation.de>
To Paolo Cavallini via RT <grass-bugs@intevation.de>
Message-id <BF7BAE65.3B33%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.0.050811
Thread-Topic [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
Thread-Index AcXUvk9Yjaed3ECxEdqp1gAKlW/i4A==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Yea! I successfully logged on to the bug tracker and reset this status to
resolved.

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: Markus Neteler via RT <grass-bugs@intevation.de>
> Reply-To: Markus Neteler via RT <grass-bugs@intevation.de>
> Date: Wed, 19 Oct 2005 13:12:17 +0200 (CEST)
> To: <michael.barton@asu.edu>
> Subject: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
> 
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3709
> 
>  Request number 3709 was given to you by 'mneteler' (Markus Neteler).
> 
> Request Tracker
> rt@intevation.de
> 
> 
> -------------------------------------------- Managed by Request Tracker


Wed, Oct 19 2005 17:31:37    Status changed to open by _rt_system  
Wed, Oct 19 2005 17:31:40    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 19 Oct 2005 08:04:51 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [bug #3709] (grass) Transaction (mneteler)
In-reply-to <20051019111258.E3EB210015D@lists.intevation.de>
To Paolo Cavallini via RT <grass-bugs@intevation.de>
Message-id <BF7BAEA3.3B34%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.0.050811
Thread-Topic [bug #3709] (grass) Transaction (mneteler)
Thread-Index AcXUvnRMsvTiIECxEdqp1gAKlW/i4A==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
I fixed this at the same time as I did the v.info button. Panel output is
redirected to a small window at the bottom of the GIS Manager.

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: Markus Neteler via RT <grass-bugs@intevation.de>
> Reply-To: Markus Neteler via RT <grass-bugs@intevation.de>
> Date: Wed, 19 Oct 2005 13:12:58 +0200 (CEST)
> To: <michael.barton@asu.edu>
> Subject: [bug #3709] (grass) Transaction (mneteler)
> 
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3709
> 
> Wed, Oct 19 2005 13:12:58: Request 3709 was acted upon.
> 
>  Transaction: Mail sent by mneteler
>  
>        Queue: grass
>         Area: grass6
>      Subject: d.m - commands output pollutes the Grass terminal
>        Owner: mbarton
>   Requestors: werchowyna@epf.pl
>       Status: open
> 
> -------------------------------------------------------------------------
> Michael,
> 
> 
> 
> since you nicely managed the xterm/v.info problem (thanks!),
> 
> do you now see a chance to also redirect the output?
> 
> 
> 
> Markus
> 
> -------------------------------------------- Managed by Request Tracker


Thu, Oct 20 2005 11:58:10    Mail sent by msieczka  
Michael,

Congrats on your d.m enhacement! Grass terminal is cleaner now. Yet there is
still one thing left - the percentage progress indicator is still printed on
the main Grass terminal. Could it be redirected into the dedicated d.m window
as well?

Maciek
Thu, Oct 20 2005 18:33:06    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 20 Oct 2005 09:32:25 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [bug #3709] (grass) Transaction (msieczka)
In-reply-to <20051020095810.37C2B101EF3@lists.intevation.de>
To Paolo Cavallini via RT <grass-bugs@intevation.de>
Message-id <BF7D14A9.1B276%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.0.050811
Thread-Topic [bug #3709] (grass) Transaction (msieczka)
Thread-Index AcXVk9pXGRciGEGHEdq17AAKlZU4cA==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Maciek,

I have no idea where the percent count-up is coming from. I think it is
default output d.rast.

Actually, there is no reason to have it directed anywhere; it could be
turned off if I had any idea of how to do it. All display processes have
obvious visual indications of their progress on the display monitor. A
progress bar is really only useful for processes without such visual
indicators (e.g., r.watershed).

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

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Maciek Sieczka via RT <grass-bugs@intevation.de>
> Reply-To: Maciek Sieczka via RT <grass-bugs@intevation.de>
> Date: Thu, 20 Oct 2005 11:58:10 +0200 (CEST)
> To: <michael.barton@asu.edu>
> Subject: [bug #3709] (grass) Transaction (msieczka)
> 
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3709
> 
> Thu, Oct 20 2005 11:58:10: Request 3709 was acted upon.
> 
>  Transaction: Mail sent by msieczka
>  
>        Queue: grass
>         Area: grass6
>      Subject: d.m - commands output pollutes the Grass terminal
>        Owner: mbarton
>   Requestors: werchowyna@epf.pl
>       Status: open
> 
> -------------------------------------------------------------------------
> Michael,
> 
> 
> 
> Congrats on your d.m enhacement! Grass terminal is cleaner now. Yet there is
> 
> still one thing left - the percentage progress indicator is still printed on
> 
> the main Grass terminal. Could it be redirected into the dedicated d.m window
> 
> as well?
> 
> 
> 
> Maciek
> 
> -------------------------------------------- Managed by Request Tracker


Thu, Oct 20 2005 20:45:00    Status changed to resolved by mbarton  
Thu, Oct 20 2005 21:25:16    Status changed to open by msieczka  
Thu, Oct 20 2005 21:25:16    Mail sent by msieczka  
Michael,

I'm reopening this bug. It is not yet resolved fully. Still the percentage
count is printed in the terminal, as you have confirmed. It is even dangerous,
not only annoying. Try this:

1. in CLI: g.remove your_fave_map
2. don't press enter yet...
3. ... because first you want to go to d.m just to display your_fave_map with
some overlays to check if really going to delete it
4. "well, it's a nice map in the end" you say and change your mind
5. go back to CLI and you see:
GRASS 6.1.cvs (location_utm33):~ > g.remove your_fave_map 100%
100%
100%
100%
100%
6. "what is that mess the hack?" you ask and propably press Enter to bring the
prompt back
7. say goodbay to your_fave_map

Other scarry scenarios possible. Ok, easy to avoid it by pressing CTRL-c each
time when switching from d.m to CLI, but also easy to forget to do it when in
hurry/tired/newbie/else.

Who can help Michael to turn off the percentage count in display commands
invoked from d.m?

Maciek
Thu, Oct 20 2005 21:53:51    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 20 Oct 2005 12:53:38 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [bug #3709] (grass) Transaction (msieczka)
In-reply-to <20051020192516.6BE19101F04@lists.intevation.de>
To Paolo Cavallini via RT <grass-bugs@intevation.de>, Maciek Sieczka <werchowyna@epf.pl>
Message-id <BF7D43D2.1B295%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.0.050811
Thread-Topic [bug #3709] (grass) Transaction (msieczka)
Thread-Index AcXVr/ZpNM8ZBkGjEdq17AAKlZU4cA==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
These are two COMPLETELY UNRELATED issues. Putting them in the same bug
report will confuse anyone trying to fix the one you mention below.

The one I fixed--the original report of printing of GIS Manager commands in
the terminal window--was because I added "puts" statements in the TclTk
scripts. This was not really a bug as I did it intentionally because I
thought people would like to see what commands were running when they pushed
the display button.

I created a new way to print out commands to a new window in the GIS
Manager. (Make sure you have the newest, newest version as there was a
"puts" command in the raster overlay that I missed getting rid of until
yesterday).

The issue you raise here has nothing to do with what I've done with the
command output. The general percentage has been printing to the terminal for
an unknown time (well before I did the most recent update of the GIS
Manager). As I said, I don't know where it comes from.

It's certainly a good thing to report a bug if it really is one. But it's a
different one than the issue you raised before.

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

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Maciek Sieczka via RT <grass-bugs@intevation.de>
> Reply-To: Maciek Sieczka via RT <grass-bugs@intevation.de>
> Date: Thu, 20 Oct 2005 21:25:16 +0200 (CEST)
> To: <michael.barton@asu.edu>
> Subject: [bug #3709] (grass) Transaction (msieczka)
> 
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3709
> 
> Thu, Oct 20 2005 21:25:16: Request 3709 was acted upon.
> 
>  Transaction: Mail sent by msieczka
>  
>        Queue: grass
>         Area: grass6
>      Subject: d.m - commands output pollutes the Grass terminal
>        Owner: mbarton
>   Requestors: werchowyna@epf.pl
>       Status: open
> 
> -------------------------------------------------------------------------
> Michael,
> 
> 
> 
> I'm reopening this bug. It is not yet resolved fully. Still the percentage
> 
> count is printed in the terminal, as you have confirmed. It is even dangerous,
> 
> not only annoying. Try this:
> 
> 
> 
> 1. in CLI: g.remove your_fave_map
> 
> 2. don't press enter yet...
> 
> 3. ... because first you want to go to d.m just to display your_fave_map with
> 
> some overlays to check if really going to delete it
> 
> 4. "well, it's a nice map in the end" you say and change your mind
> 
> 5. go back to CLI and you see:
> 
> GRASS 6.1.cvs (location_utm33):~ > g.remove your_fave_map 100%
> 
> 100%
> 
> 100%
> 
> 100%
> 
> 100%
> 
> 6. "what is that mess the hack?" you ask and propably press Enter to bring
the
> 
> prompt back
> 
> 7. say goodbay to your_fave_map
> 
> 
> 
> Other scarry scenarios possible. Ok, easy to avoid it by pressing CTRL-c each
> 
> time when switching from d.m to CLI, but also easy to forget to do it when
in
> 
> hurry/tired/newbie/else.
> 
> 
> 
> Who can help Michael to turn off the percentage count in display commands
> 
> invoked from d.m?
> 
> 
> 
> Maciek
> 
> -------------------------------------------- Managed by Request Tracker


Thu, Oct 20 2005 22:19:10    Mail sent by msieczka  
Michael wrote:
> These are two COMPLETELY UNRELATED issues

These are two very related issues IMO. Grass terminal is still polluted, and
the pollution is coming from the d.m commands.

I absolutely agree that you did a large most of the work needed to stop CLI
being polluted by the d.m, you did all you can and you did it very good. I
hope you don't have the impression I neglect your effort. That's not my
intention. I like your d.m enhacement and kudo to your (continous) effort.

I see however the point is you can't do much more about the remaining issue.
Thus, if you don't mind, I change the owner back to Mr. Nobody and we have to
wait for some volunteer to continue your work. Let me know if mind it, off RT
please to keep the thread possibly clean. I have just added garbage enough ;).
The other reason I reopened this report instead of creating a new one is that
I was told by Hamish on grassdevel list not to do so if not necesssary, so we
could trace all the bug's history easily. I also believe we don't have to
change the report's title as it stil reflects the issue's nature.

Maciek
Fri, Oct 21 2005 01:29:54    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 20 Oct 2005 16:28:26 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
In-reply-to <20051020201910.B2EEB101F00@lists.intevation.de>
To Paolo Cavallini via RT <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Message-id <BF7D762A.1B2AE%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.0.050811
Thread-Topic [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
Thread-Index AcXVzfhBNpurs0HBEdq17AAKlZU4cA==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Maciek

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.

Michael


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

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Maciek Sieczka via RT <grass-bugs@intevation.de>
> Reply-To: Maciek Sieczka via RT <grass-bugs@intevation.de>
> Date: Thu, 20 Oct 2005 22:19:10 +0200 (CEST)
> Cc: <grass5@grass.itc.it>, <Michael.Barton@asu.edu>
> Subject: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
> 
> Michael wrote:
> 
>> These are two COMPLETELY UNRELATED issues
> 
> 
> 
> These are two very related issues IMO. Grass terminal is still polluted, and
> 
> the pollution is coming from the d.m commands.
> 
> 
> 
> I absolutely agree that you did a large most of the work needed to stop CLI
> 
> being polluted by the d.m, you did all you can and you did it very good. I
> 
> hope you don't have the impression I neglect your effort. That's not my
> 
> intention. I like your d.m enhacement and kudo to your (continous) effort.
> 
> 
> 
> I see however the point is you can't do much more about the remaining issue.
> 
> Thus, if you don't mind, I change the owner back to Mr. Nobody and we have
to
> 
> wait for some volunteer to continue your work. Let me know if mind it, off
RT
> 
> please to keep the thread possibly clean. I have just added garbage enough
;).
> 
> 
> 
> The other reason I reopened this report instead of creating a new one is that
> 
> I was told by Hamish on grassdevel list not to do so if not necesssary, so
we
> 
> could trace all the bug's history easily. I also believe we don't have to
> 
> change the report's title as it stil reflects the issue's nature.
> 
> 
> 
> Maciek
> 
> -------------------------------------------- Managed by Request Tracker


Fri, Oct 21 2005 15:28:26    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17240.60649.496309.230870@cerise.gclements.plus.com>
Date Fri, 21 Oct 2005 14:28:09 +0100
To Michael Barton <michael.barton@asu.edu>
Cc Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
In-Reply-To <BF7D762A.1B2AE%michael.barton@asu.edu>
References <20051020201910.B2EEB101F00@lists.intevation.de> <BF7D762A.1B2AE%michael.barton@asu.edu>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Michael Barton 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.

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


Fri, Oct 21 2005 15:54:12    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17240.62205.452526.433110@cerise.gclements.plus.com>
Date Fri, 21 Oct 2005 14:54:05 +0100
To Michael Barton <michael.barton@asu.edu>, Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
In-Reply-To <17240.60649.496309.230870@cerise.gclements.plus.com>
References <20051020201910.B2EEB101F00@lists.intevation.de> <BF7D762A.1B2AE%michael.barton@asu.edu> <17240.60649.496309.230870@cerise.gclements.plus.com>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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@gclements.plus.com>


Fri, Oct 21 2005 17:19:21    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 21 Oct 2005 08:18:27 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
In-reply-to <17240.62205.452526.433110@cerise.gclements.plus.com>
To Glynn Clements <glynn@gclements.plus.com>, Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Message-id <BF7E54D3.3C1A%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.0.050811
Thread-Topic [GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
Thread-Index AcXWUq+A7iugn0JFEdqp1gAKlW/i4A==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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@gclements.plus.com>
> Date: Fri, 21 Oct 2005 14:54:05 +0100
> To: Michael Barton <michael.barton@asu.edu>, Paolo Cavallini via RT
> <grass-bugs@intevation.de>, <grass5@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@gclements.plus.com>


Sat, Oct 22 2005 14:01:40    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17242.10777.588441.475130@cerise.gclements.plus.com>
Date Sat, 22 Oct 2005 13:01:29 +0100
To Michael Barton <michael.barton@asu.edu>
Cc Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
In-Reply-To <BF7E54D3.3C1A%michael.barton@asu.edu>
References <17240.62205.452526.433110@cerise.gclements.plus.com> <BF7E54D3.3C1A%michael.barton@asu.edu>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Michael Barton wrote:

> 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?

Ideally it would use the internal log window, but redirecting to
/dev/null is probably the next best thing.

Note that if the terminal has the TOSTOP flag set (i.e. "stty tostop"),
a background process which tries to write to the terminal
will be suspended, which is undesirable.

In any case, stderr has to be redirected somewhere, as exec generates
an error if anything is written to stderr and it hasn't been
redirected.

> 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.

Try the following (untested):

	proc cmd_output {fh} {
		global outtext
		while {![eof $fh]} {
			set str [gets $fh]
			append str "\n"
			if { [fblocked $fh] } { set str [read $fh] }
			while {[set idx [string first "\b" $str]] != -1} {
				set last [expr $idx - 1]
				set str1 [string range $str 1 $last]
				set first [expr $idx + 1]
				set str [string range $str $first end]
				set pos [$outtext index "end - 1 chars"]
				$outtext delete $pos
				$outtext insert end $str1
			}
			$outtext insert end $str
			$outtext yview end
			update idletasks
		}
		close $fh
	}

	proc run_panel {cmd} {
		global outtext
		set cmd [concat | $cmd 2>@ stdout]
		if { [catch {open $cmd r} fh] } {
			error $fh
		}
		$outtext insert end "$cmd\n"
		$outtext yview end
		cmd_output $fh
	}

This differs from the mechanism used in gui.tcl, as run_panel needs to
wait until the command has completed before it returns.

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


Sat, Oct 22 2005 18:12:34    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Sat, 22 Oct 2005 09:12:24 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
In-reply-to <17242.10777.588441.475130@cerise.gclements.plus.com>
To Glynn Clements <glynn@gclements.plus.com>
Cc Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Message-id <BF7FB2F8.3C5F%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.0.050811
Thread-Topic [GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
Thread-Index AcXXI2NQoeHJDEMWEdqp1gAKlW/i4A==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Thanks Glynn. I'll try this.

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@gclements.plus.com>
> Date: Sat, 22 Oct 2005 13:01:29 +0100
> To: Michael Barton <michael.barton@asu.edu>
> Cc: Paolo Cavallini via RT <grass-bugs@intevation.de>, <grass5@grass.itc.it>
> Subject: Re: [GRASS5] Re: [bug #3709] (grass) d.m - commands output pollutes
> the Grass terminal
> 
> 
> Michael Barton wrote:
> 
>> 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?
> 
> Ideally it would use the internal log window, but redirecting to
> /dev/null is probably the next best thing.
> 
> Note that if the terminal has the TOSTOP flag set (i.e. "stty tostop"),
> a background process which tries to write to the terminal
> will be suspended, which is undesirable.
> 
> In any case, stderr has to be redirected somewhere, as exec generates
> an error if anything is written to stderr and it hasn't been
> redirected.
> 
>> 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.
> 
> Try the following (untested):
> 
> proc cmd_output {fh} {
> global outtext
> while {![eof $fh]} {
> set str [gets $fh]
> append str "\n"
> if { [fblocked $fh] } { set str [read $fh] }
> while {[set idx [string first "\b" $str]] != -1} {
> set last [expr $idx - 1]
> set str1 [string range $str 1 $last]
> set first [expr $idx + 1]
> set str [string range $str $first end]
> set pos [$outtext index "end - 1 chars"]
> $outtext delete $pos
> $outtext insert end $str1
> }
> $outtext insert end $str
> $outtext yview end
> update idletasks
> }
> close $fh
> }
> 
> proc run_panel {cmd} {
> global outtext
> set cmd [concat | $cmd 2>@ stdout]
> if { [catch {open $cmd r} fh] } {
> error $fh
> }
> $outtext insert end "$cmd\n"
> $outtext yview end
> cmd_output $fh
> }
> 
> This differs from the mechanism used in gui.tcl, as run_panel needs to
> wait until the command has completed before it returns.
> 
> -- 
> Glynn Clements <glynn@gclements.plus.com>


Wed, Oct 26 2005 15:55:17    Status changed to resolved by msieczka  
Wed, Oct 26 2005 15:55:17    Mail sent by msieczka  
Fixed by Michael Barton.

Maciek
Mon, Jan 9 2006 15:26:33    Status changed to open by msieczka  
Mon, Jan 9 2006 15:30:35    Mail sent by msieczka  
d.m still prints some output to the terminal - when opening new monitors:

press eg. "x1":

GRASS 6.1.cvs (caves_xy):~ > using default visual which is TrueColor
ncolors: 16777216
Graphics driver [x1] started

Could that be redirected to the d.m log window too?

Maciek
Mon, Jan 9 2006 17:46:54    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 09 Jan 2006 09:46:40 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [bug #3709] (grass) Transaction (msieczka)
In-reply-to <20060109143035.8518E100161@lists.intevation.de>
To Paolo Cavallini via RT <grass-bugs@intevation.de>, Maciek Sieczka <werchowyna@epf.pl>, grass5 <grass5@grass.itc.it>
Message-id <BFE7E180.1D247%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.1.051004
Thread-Topic [bug #3709] (grass) Transaction (msieczka)
Thread-Index AcYVPENrgefVhIEvEdq9jwAUUSYxwg==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
This cannot be avoided. The output cannot be redirected given the way that
d.mon works. You can either leave this open or (perhaps better) redirect it
to someone who can change d.mon.

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

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Maciek Sieczka via RT <grass-bugs@intevation.de>
> Reply-To: Maciek Sieczka via RT <grass-bugs@intevation.de>
> Date: Mon,  9 Jan 2006 15:30:35 +0100 (CET)
> To: <michael.barton@asu.edu>
> Subject: [bug #3709] (grass) Transaction (msieczka)
> 
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3709
> 
> Mon, Jan 9 2006 15:30:35: Request 3709 was acted upon.
> 
>  Transaction: Mail sent by msieczka
>  
>        Queue: grass
>         Area: grass6
>      Subject: d.m - commands output pollutes the Grass terminal
>        Owner: mbarton
>   Requestors: werchowyna@epf.pl
>       Status: open
> 
> -------------------------------------------------------------------------
> d.m still prints some output to the terminal - when opening new monitors:
> 
> 
> 
> press eg. "x1":
> 
> 
> 
> GRASS 6.1.cvs (caves_xy):~ > using default visual which is TrueColor
> 
> ncolors: 16777216
> 
> Graphics driver [x1] started
> 
> 
> 
> Could that be redirected to the d.m log window too?
> 
> 
> 
> Maciek
> 
> -------------------------------------------- Managed by Request Tracker


Mon, Jan 9 2006 20:02:23    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17346.45883.87211.308121@cerise.gclements.plus.com>
Date Mon, 9 Jan 2006 19:02:19 +0000
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3709] (grass) d.m - commands output pollutes the Grass terminal
In-Reply-To <20060109143035.8AEC41006AF@lists.intevation.de>
References <20060109143035.8AEC41006AF@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Maciek Sieczka via RT wrote:

> d.m still prints some output to the terminal - when opening new monitors:
> 
> press eg. "x1":
> 
> GRASS 6.1.cvs (caves_xy):~ > using default visual which is TrueColor
> ncolors: 16777216
> Graphics driver [x1] started
> 
> Could that be redirected to the d.m log window too?

That case is problematic. The reason is that it's the monitor driver
which displays the text. If you allow the output from "d.mon start="
to be returned to Tcl, the command won't finish until the driver
terminates.

Apart from anything else, this means that you can't quit d.m and leave
the monitor open.

The only practical solution is to redirect the output somewhere,
either to the terminal on which d.m is running, to a file, or to
/dev/null.

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


Fri, Jun 23 2006 21:54:14    Status changed to resolved by mbarton  
Fri, Jun 23 2006 21:54:14    Mail sent by mbarton  
This is fixed to the extent possible in d.m. It is resolved completely in gis.m.
Comment | Reply | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request