Details Ticket 4524


Comment | Reply | Take | Resolve


Serial Number 4524
Subject v.clean, v.patch (else?): output to stderr instead of stdout...
Area grass6
Queue grass
Requestors tutey@o2.pl
Owner none
Status open
Last User Contact Sat Jul 15 05:37:45 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Jul 26 18:44:09 2006 (2 yr ago)
Created Tue May 30 20:57:09 2006 (2 yr ago)

Transaction History Ticket 4524


Tue, May 30 2006 20:57:09    Request created by guest  
Subject: v.clean, v.patch (else?): output to stderr instead of stdout...

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 2006-05-30

...and it is hard to prevent such commands from being verbose when not supposed
to, "> /dev/null" doesn't help.

Especially v.clean is a big mouth.

It is a pain in user's scripts.

Maciek
Wed, May 31 2006 05:22:44    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 31 May 2006 15:22:36 +1200
From Hamish <hamish_nospam@yahoo.com>
To Request Tracker <grass-bugs@intevation.de>
Cc grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #4524] (grass) v.clean, v.patch (else?): output to stderr instead of stdout...
Message-Id <20060531152236.1d10b389.hamish_nospam@yahoo.com>
In-Reply-To <20060530185709.4E5D51006AD@lists.intevation.de>
References <20060530185709.4E5D51006AD@lists.intevation.de>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4524
> ---------------------------------------------------------------------
> 
> Subject: v.clean, v.patch (else?): output to stderr instead of
> stdout...
..
> GRASS Version: 2006-05-30
> 
> ...and it is hard to prevent such commands from being verbose when not
> supposed to, "> /dev/null" doesn't help.
 
"2> /dev/null" might help, but then you might lose error/warnings.


> Especially v.clean is a big mouth.



v.patch:
    Vect_build (&OutMap, stdout);
    Vect_close (&OutMap);

    fprintf (stderr, "Patch complete. %d files patched.\n", n_files);
    fprintf (stderr, "Intersections at borders will have to be snapped.\n");
fprintf (stderr, "Lines common between files will have to be edited.\n");
    fprintf (stderr, "The header information also may have to be edited.\n");
As discussed recently on grass5, those fprintf's should use G_message(),
then G_message(),G_percent() should check some verbosity variable.

This will clean up a lot.

Vect_build() is harder as the intended output is specific. Modify each
module that uses Vect_build() or test in Vect_build() for != "std*"?


Hamish


Fri, Jul 7 2006 17:00:00    Mail sent by mneteler  
Hi,

still an issue? the fprintf's have been changed in
v.patch.

Markus
Fri, Jul 7 2006 21:49:26    Mail sent by msieczka  
On Fri,  7 Jul 2006 17:00:00 +0200 (CEST)
Markus Neteler via RT <grass-bugs@intevation.de> wrote:

> still an issue? the fprintf's have been changed in v.patch.

Yes.

v.patch still prints to terminal instead of /dev/null. There is no difference
to before the change you mention, ie.:

 $ v.patch input=map1,map2 output=map3 >/dev/null
 Patching file map1
 Patching file map2
 Patch complete. 2 files patched.
 Intersections at borders will have to be snapped.
 Lines common between files will have to be edited.
 The header information also may have to be edited.

The above 6 lines should all go to /dev/null, too. v.clean is even worse -
*not a single line* is redirected to /dev/null, so each v.clean run results in
about 40 lines printed to the terminal.

Maciek
Mon, Jul 10 2006 08:44:30    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 10 Jul 2006 18:44:10 +1200
From Hamish <hamish_nospam@yahoo.com>
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #4524] (grass) v.clean, v.patch (else?): output to stderr instead of stdout...
Message-Id <20060710184410.37a73969.hamish_nospam@yahoo.com>
In-Reply-To <20060707194926.7849B10015B@lists.intevation.de>
References <20060707194926.7849B10015B@lists.intevation.de>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-1.559 tagged_above=-999 required=4 tests=[AWL=1.346, BAYES_00=-5, FORGED_YAHOO_RCVD=2.095]
X-Spam-Level
Maciek Sieczka wrote:

> > still an issue? the fprintf's have been changed in v.patch.
> 
> Yes.
> 
> v.patch still prints to terminal instead of /dev/null. There is no
> difference to before the change you mention, ie.:
> 
>  $ v.patch input=map1,map2 output=map3 >/dev/null
>  Patching file map1
>  Patching file map2
>  Patch complete. 2 files patched.
>  Intersections at borders will have to be snapped.
>  Lines common between files will have to be edited.
>  The header information also may have to be edited.
> 
> The above 6 lines should all go to /dev/null, too. v.clean is even
> worse - *not a single line* is redirected to /dev/null, so each
> v.clean run results in about 40 lines printed to the terminal.


GRASS sends general messages to stderr and parsable output to stdout.

to redirect stderr to /dev/null do:

G61> v.patch input=map1,map2 output=map3 2> /dev/null


note this will send errors and warnings to /dev/null too, which may not
be what you want.

most modules should be quiet by default (I think ESR asks for "only
display output if something surprising happens"), but include a -v
verbose flag if verbose output could be interesting (e.g. long running
modules). Really long running modules may want to send some heartbeat or
status messages.

> G> v.patch input=map1,map2 output=map3 >/dev/null
>  Patching file map1
>  Patching file map2

These look like they might be put behind a -v verbose flag or
G_debug(1,"");

>  Patch complete. 2 files patched.
>  Intersections at borders will have to be snapped.
>  Lines common between files will have to be edited.
>  The header information also may have to be edited.

These look like they should remain with G_message().


Hamish


Mon, Jul 10 2006 09:08:20    Mail sent by tutey@o2.pl  
Return-Path <tutey@o2.pl>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 10 Jul 2006 09:08:13 +0200
From Maciej Sieczka <tutey@o2.pl>
To grass-dev@grass.itc.it
Cc grass-bugs@intevation.de
Subject Re: [bug #4524] (grass) v.clean, v.patch (else?):
Message-ID <20060710090813.3bbbe8df@sorbus>
In-Reply-To <20060710064430.BE7B1100160@lists.intevation.de>
References <20060710064430.BE7B1100160@lists.intevation.de>
X-Mailer Sylpheed-Claws 2.3.1 (GTK+ 2.8.18; i486-pc-linux-gnu)
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-4.734 tagged_above=-999 required=4 tests=[BAYES_00=-5, FORGED_RCVD_HELO=0.266]
X-Spam-Level
Mon, 10 Jul 2006 08:44:30 +0200 (CEST)
Hamish via RT <grass-bugs@intevation.de> wrote:

> Maciek Sieczka wrote:
> 
> > > still an issue? the fprintf's have been changed in v.patch.
> > 
> > Yes.
> > 
> > v.patch still prints to terminal instead of /dev/null. There is no
> > difference to before the change you mention, ie.:
> > 
> >  $ v.patch input=map1,map2 output=map3 >/dev/null
> >  Patching file map1
> >  Patching file map2
> >  Patch complete. 2 files patched.
> >  Intersections at borders will have to be snapped.
> >  Lines common between files will have to be edited.
> >  The header information also may have to be edited.
> > 
> > The above 6 lines should all go to /dev/null, too. v.clean is even
> > worse - *not a single line* is redirected to /dev/null, so each
> > v.clean run results in about 40 lines printed to the terminal.
> 
> 
> GRASS sends general messages to stderr and parsable output to stdout.
> 
> to redirect stderr to /dev/null do:
> 
> G61> v.patch input=map1,map2 output=map3 2> /dev/null

> note this will send errors and warnings to /dev/null too, which may
> not be what you want.

You are right, that is not a solution. We want errors and warnings be
let through.

> most modules should be quiet by default (I think ESR asks for "only
> display output if something surprising happens"), but include a -v
> verbose flag if verbose output could be interesting (e.g. long running
> modules). Really long running modules may want to send some heartbeat
> or status messages.
> 
> > G> v.patch input=map1,map2 output=map3 >/dev/null
> >  Patching file map1
> >  Patching file map2
> 
> These look like they might be put behind a -v verbose flag or
> G_debug(1,"");
> 
> >  Patch complete. 2 files patched.
> >  Intersections at borders will have to be snapped.
> >  Lines common between files will have to be edited.
> >  The header information also may have to be edited.
> 
> These look like they should remain with G_message().

What for? >/dev/null should result in filtering out all standard
information. Only information in case of unexpected module behaviour
should be let through. This will make user's scripts output cleaner.
The above info is usefull for a single v.patch run, to give guiding to
the user on how to proceed. But when v.patch is called from a script it
is script's author responsibility to be aware of such caveats and use
v.patch properly. IOW, when v.patch is called from a script the standard
message above is not improving anything but decreases the output 
clarity.

Same for v.clean or any other module.

Maciek


Mon, Jul 10 2006 11:24:12    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 10 Jul 2006 21:23:57 +1200
From Hamish <hamish_nospam@yahoo.com>
To Maciej Sieczka <tutey@o2.pl>
Cc grass-dev@grass.itc.it, grass-bugs@intevation.de
Subject Re: [GRASS-dev] Re: [bug #4524] (grass) v.clean, v.patch (else?):
Message-Id <20060710212357.14241762.hamish_nospam@yahoo.com>
In-Reply-To <20060710090813.3bbbe8df@sorbus>
References <20060710064430.BE7B1100160@lists.intevation.de> <20060710090813.3bbbe8df@sorbus>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-1.588 tagged_above=-999 required=4 tests=[AWL=1.317, BAYES_00=-5, FORGED_YAHOO_RCVD=2.095]
X-Spam-Level
Maciej Sieczka wrote:
..
> > > The above 6 lines should all go to /dev/null, too. v.clean is even
> > > worse - *not a single line* is redirected to /dev/null, so each
> > > v.clean run results in about 40 lines printed to the terminal.
> > 
> > GRASS sends general messages to stderr and parsable output to
> > stdout.
..
> What for? >/dev/null should result in filtering out all standard
> information. Only information in case of unexpected module behaviour
> should be let through. This will make user's scripts output cleaner.
> The above info is usefull for a single v.patch run, to give guiding to
> the user on how to proceed. But when v.patch is called from a script
> it is script's author responsibility to be aware of such caveats and
> use v.patch properly. IOW, when v.patch is called from a script the
> standard message above is not improving anything but decreases the
> output clarity.
> 
> Same for v.clean or any other module.


fyi, v.clean and any module that builds topology with Vect_build() sends
as its second argument the destination of messages. for v.clean this is:

Vect_build (pErr, stderr);

distribution is as follows:
$ cd vector/
$ grep -rI Vect_build * | grep stdout | wc -l
31
$ grep -rI Vect_build * | grep stderr | wc -l
41

clearly not standardized; this should be fixed to either one or the
other for most modules.

It is indeed arguable (as you suggest) that modules which will not
produce parsable output should have status messages sent to stdout. IMO
this would lead to a mess- GUIs, etc, couldn't redirect std* en masse
and presume that all modules will work as expected. Scripts would have
to be crafted for each module's needs individually.

The correct solution IMO is to relegate overly verbose messages to
G_debug(1,) or a -v verbose flag, and continue to send warnings and
errors to stderr.

> >  Patch complete. 2 files patched.

in effect G_done_msg().

> >  Intersections at borders will have to be snapped.
> >  Lines common between files will have to be edited.
> >  The header information also may have to be edited.

These 3 are somewhere between needing Warnings and boldface type in the
help page. (hence G_message())


The question might be reduced to "where to send G_message()?" ?


Hamish


Wed, Jul 12 2006 10:33:45    Mail sent by msieczka  
Hamish wrote (Mon, Jul 10 2006 11:24:12):

> The correct solution IMO is to relegate overly verbose messages to
> G_debug(1,) or a -v verbose flag, and continue to send warnings and
> errors to stderr.
> 
> > >  Patch complete. 2 files patched.
> 
> in effect G_done_msg().
> 
> > >  Intersections at borders will have to be snapped.
> > >  Lines common between files will have to be edited.
> > >  The header information also may have to be edited.
> 
> These 3 are somewhere between needing Warnings and boldface type in the
> help page. (hence G_message())
> 
> 
> The question might be reduced to "where to send G_message()?" ?

Anywhere but stdout, I think.

Example reason: I don't want somebody using my v.flip (a script that calls
v.patch, among the others) to be confused with v.patch information that:

# Intersections at borders will have to be snapped.
# Lines common between files will have to be edited.
# The header information also may have to be edited.

Because I have taken care of this for the user, knowing what the input for
v.patch is and using 'v.clean tool=snap' as needed. That information above is
simply wrong and confusing the user, when v.patch is a script component.

Maciek
Sat, Jul 15 2006 05:37:45    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Sat, 15 Jul 2006 15:37:38 +1200
From Hamish <hamish_nospam@yahoo.com>
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc grass-dev@grass.itc.it
Subject Re: [bug #4524] (grass) v.clean, v.patch (else?): output to stderr instead of stdout...
Message-Id <20060715153738.557352ea.hamish_nospam@yahoo.com>
In-Reply-To <20060712083345.54E541006A5@lists.intevation.de>
References <20060712083345.54E541006A5@lists.intevation.de>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-1.609 tagged_above=-999 required=4 tests=[AWL=1.296, BAYES_00=-5, FORGED_YAHOO_RCVD=2.095]
X-Spam-Level
> > The question might be reduced to "where to send G_message()?" ?
> 
> Anywhere but stdout, I think.
> 
> Example reason: I don't want somebody using my v.flip (a script that
> calls v.patch, among the others) to be confused with v.patch
> information that:
> 
> # Intersections at borders will have to be snapped.
> # Lines common between files will have to be edited.
> # The header information also may have to be edited.
> 
> Because I have taken care of this for the user, knowing what the input
> for v.patch is and using 'v.clean tool=snap' as needed. That
> information above is simply wrong and confusing the user, when v.patch
> is a script component.

No a general solution, but for your script perhaps you could use
"grep -v" or sed to filter out the unwanted messages (after redirecting
stderr to stdout as needed)?


Hamish


Wed, Jul 26 2006 18:44:09    User changed to tutey@o2.pl by msieczka  
Comment | Reply | Take | Resolve

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