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