[GRASS-dev] Re: [GRASSLIST:962] Re: GRASS and vector lines: how can I change the direction of digitized lines?

[Maciej_Sieczka3]

n Fri, 28 Apr 2006 13:35:32 +0200
wqual <wolfgang.qual@gmx.net> wrote:

<snip>

b) how can I change the direction of the lines in GRASS?

Hi All,

I've been looking for this functionality too. Following Markus
suggestion, I have written a script to flip directions of selected
Grass line vectors, all done within Grass.

This is my first ehm full-blown Grass script. I will be very gratefull
for any comments and guiding on how to improve it.

I'm especially interested in the following:

1. Is there another way to safely create temporary vector files than I
do (ie. use a likely unique name, check if it doesn't exist yet in the
mapset, proceed if not, else stop and issue a warning).

2. I use "v.clean tool=snap thresh=0.01" to re-connect the flipped and
the remaining original lines. Is it 100% robust? No risk that some
won't be connected?

Wolfgang,

Can you see if it works for you? Backup your data first!

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

(attachments)

v.flip (5.72 KB)

[H_B]

Hi,

some hints follow,

I've been looking for this functionality too. Following Markus
suggestion, I have written a script to flip directions of selected
Grass line vectors, all done within Grass.

This is my first ehm full-blown Grass script. I will be very gratefull
for any comments and guiding on how to improve it.

I'm especially interested in the following:

1. Is there another way to safely create temporary vector files than I
do (ie. use a likely unique name, check if it doesn't exist yet in the
mapset, proceed if not, else stop and issue a warning).

you are already using g.tempfile + success tests correctly.

2. I use "v.clean tool=snap thresh=0.01" to re-connect the flipped and
the remaining original lines. Is it 100% robust? No risk that some
won't be connected?

If anything I would make thresh much smaller so that no new lines are
snapped. The coordinates should not be changed unless you did printf %f
from awk (shortens decimal precision, use %s to output full input string
instead of proccessing as a number). So snapping should be exact.

eval `g.findfile element=vector file="$INPUT"`
    if [ ! "$file" ] ; then

can be shortened, g.findfile returns 1 if the file wasn't found.
see r.blend:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/scripts/r.blend/r.blend?rev=HEAD

just leave those tests out for input= and output=, g.parser checks
that maps do/don't exist given the rules in "#% gisprompt :",
--overwrite, etc.

Call temporary maps like tmp_vflip_$$_toflip:
tmp_${PROG} makes it easy to spot orphans, $$ gives it a 1 in 32k chance
of being unique.

It is easier to read, if instead of

output=$OUTPUT"_toflip"
  you do
output=${OUTPUT}_toflip
  or
output="${OUTPUT}_toflip"

you probably want to use "sort -n" instead of "sort" so you don't get
1
13
2
20
etc.

asis=`cat $TMP.cat_asis`
asis=`echo $asis | sed 's/ /,/g'`
probably hit the limitied size cap for a shell variable? (4096 chars?)
Use a tmp file.

for a in $start_stop
do
..
done

make it easier to follow by indenting the inner part of the loop by a
few spaces.

see also v.out.ascii.db (wiki add-ons) and v.in.garmin (complex awk+tac
vector ascii format flipping to count vertices) scripts.

Hamish

[Maciej_Sieczka3]

Hamish, All,

Improved (still to be improved further) v.flip 1.1 is attached. Please
take a look at my writing below.

On Mon, 15 May 2006 15:29:03 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

some hints follow,

<snip>

Maciek wrote:

2. I use "v.clean tool=snap thresh=0.01" to re-connect the flipped
and the remaining original lines. Is it 100% robust? No risk that
some won't be connected?

If anything I would make thresh much smaller so that no new lines are
snapped. The coordinates should not be changed unless you did printf %f
from awk (shortens decimal precision, use %s to output full input
string instead of proccessing as a number). So snapping should be
exact.

I see. I don't do any maths on coordinates, I only use awk to select
particular lines from v.out.ascii output and pipe them into another
file, in a given order, so I should be on the safe side here.

Is it possible to estimate what treshold should be enough? 0.0001,
else???

eval `g.findfile element=vector file="$INPUT"`
   if [ ! "$file" ] ; then

can be shortened, g.findfile returns 1 if the file wasn't found.
see r.blend:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/scripts/r.blend/r.blend?rev=HEAD

just leave those tests out for input= and output=, g.parser checks
that maps do/don't exist given the rules in "#% gisprompt :",
--overwrite, etc.

These are cool, thanks. Done.

Call temporary maps like tmp_vflip_$$_toflip:
tmp_${PROG} makes it easy to spot orphans, $$ gives it a 1 in 32k
chance of being unique.

I'm already using $$, I think (TMP="`g.tempfile pid=$$`"). Is this
what you mean? Added $PROG, thanks.

It is easier to read, if instead of

output=$OUTPUT"_toflip"
you do
output=${OUTPUT}_toflip
or
output="${OUTPUT}_toflip"

Is the 1st one error prone or only "not nice"?

Is any of the 2 you recommend better? I'll correct my script
accordingly.

you probably want to use "sort -n" instead of "sort" so you don't get
1
13
2
20
etc.

In my case it doesn't matter - I only need to put identical words one
after another to filter out only 1 instance of each of them with uniq.

asis=`cat $TMP.cat_asis`
asis=`echo $asis | sed 's/ /,/g'`
probably hit the limitied size cap for a shell variable? (4096 chars?)
Use a tmp file.

Hmm, $asis is an input in the line 129:

v.extract -t layer=$LAYER input=$INPUT list=$asis output=
$OUTPUT"_leaveasis"

list= has to be a single, long string of numbers separated with ",". So
even if I avoid hitting the 4096 chars limit of a bash variable by
doing all in a TMP file, I will finally have to pass it to "v.extract
list=" as a one string, which will make it fail if the string is
longer than 4096 (is my thinking correct?).

A possible workaround would be to to convert long, continous sets
like eg. 1,2,3,4,5,...,100 into 1-100 and so on to save space. Is there
an easy way of doing it?

for a in $start_stop
do
..
done

make it easier to follow by indenting the inner part of the loop by a
few spaces.

see also v.out.ascii.db (wiki add-ons) and v.in.garmin (complex awk+tac
vector ascii format flipping to count vertices) scripts.

Thank you very much for all the hints. I really appreciate your help.

All Best,
Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

(attachments)

v.flip_11 (4.86 KB)

[H_B]

>> 2. I use "v.clean tool=snap thresh=0.01" to re-connect the flipped
>> and the remaining original lines. Is it 100% robust? No risk that
>> some won't be connected?

>If anything I would make thresh much smaller so that no new lines are
>snapped. The coordinates should not be changed unless you did printf
>%f from awk (shortens decimal precision, use %s to output full input
>string instead of proccessing as a number). So snapping should be
>exact.

I see. I don't do any maths on coordinates, I only use awk to select
particular lines from v.out.ascii output and pipe them into another
file, in a given order, so I should be on the safe side here.

Is it possible to estimate what treshold should be enough? 0.0001,
else???

So the coordinates haven't moved and should line up exactly. Thus
a tresh of 0.0 should catch them, but as a general rule floating point
numbers are of finite precision so it is usually better to test if
(a1-a2 < 1e-15) or so.

But this is mostly academic, anything smaller than a centimeter should
probably be snapped and your original value of 0.01 should be fine.
(unless this is a lat/lon location &/or your units are not meters!)
This means your module "touches the data" and isn't a fully reversable
proceedure, which may not be desired.

>Call temporary maps like tmp_vflip_$$_toflip:
>tmp_${PROG} makes it easy to spot orphans, $$ gives it a 1 in 32k
>chance of being unique.

I'm already using $$, I think (TMP="`g.tempfile pid=$$`"). Is this
what you mean? Added $PROG, thanks.

$$ gives current process id number. adding it to the map name means
multiple runs of v.flip won't collide if an earlier one broke.

$PROG is ok for tmp filenames but a bad idea for vector map names -- you
can't use "." in a vector map's name. Just helps you spot where strange
left over files came from in a week's time.

>It is easier to read, if instead of
>
>output=$OUTPUT"_toflip"
> you do
>output=${OUTPUT}_toflip
> or
>output="${OUTPUT}_toflip"

Is the 1st one error prone or only "not nice"?

Is any of the 2 you recommend better? I'll correct my script
accordingly.

all work, just cleaner to use. Quoting the whole thing only matters if
you have special characters in the map name, which are illegal anyway.
Hopefully then you get an informative GRASS error instead of a cryptic
bash error.

>asis=`cat $TMP.cat_asis`
>asis=`echo $asis | sed 's/ /,/g'`
>probably hit the limitied size cap for a shell variable? (4096
>chars?) Use a tmp file.

Hmm, $asis is an input in the line 129:

v.extract -t layer=$LAYER input=$INPUT list=$asis output=
$OUTPUT"_leaveasis"

list= has to be a single, long string of numbers separated with ",".
So even if I avoid hitting the 4096 chars limit of a bash variable by
doing all in a TMP file, I will finally have to pass it to "v.extract
list=" as a one string, which will make it fail if the string is
longer than 4096 (is my thinking correct?).

ok. maybe better to use an SQL query then where= cat is not flip_list?
Don't know how to specify that. v.select doesn't have op=not, maybe need
v.overlay? If only flipping a few of several thousand lines you may have
trouble.

doesn't help here, but you can go back and forth from a list in a file
to csv with the "tr"ade unix command:

tr '\n' ','
and
tr ',' '\n'

(same as sed 's/\n/,/g' )

A possible workaround would be to to convert long, continous sets
like eg. 1,2,3,4,5,...,100 into 1-100 and so on to save space. Is
there an easy way of doing it?

don't know.

Thank you very much for all the hints.

You already had it working, which is the hard part. A lot of this is
just tricks to make the code simpler & easier to catch errors.

Hamish

[Maciej_Sieczka3]

(I've already sent this message yesterday, but it didn't make it to the
list, thus resending)

Hamish, All,

Improved (still to be improved further) v.flip 1.1 is attached. Please
take a look at my writing below.

On Mon, 15 May 2006 15:29:03 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

some hints follow,

<snip>

Maciek wrote:

2. I use "v.clean tool=snap thresh=0.01" to re-connect the flipped
and the remaining original lines. Is it 100% robust? No risk that
some won't be connected?

If anything I would make thresh much smaller so that no new lines are
snapped. The coordinates should not be changed unless you did printf %f
from awk (shortens decimal precision, use %s to output full input
string instead of proccessing as a number). So snapping should be
exact.

I see. I don't do any maths on coordinates, I only use awk to select
particular lines from v.out.ascii output and pipe them into another
file, in a given order, so I should be on the safe side here.

Is it possible to estimate what treshold should be enough? 0.0001,
else???

eval `g.findfile element=vector file="$INPUT"`
   if [ ! "$file" ] ; then

can be shortened, g.findfile returns 1 if the file wasn't found.
see r.blend:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/scripts/r.blend/r.blend?rev=HEAD

just leave those tests out for input= and output=, g.parser checks
that maps do/don't exist given the rules in "#% gisprompt :",
--overwrite, etc.

These are cool, thanks. Done.

Call temporary maps like tmp_vflip_$$_toflip:
tmp_${PROG} makes it easy to spot orphans, $$ gives it a 1 in 32k
chance of being unique.

I'm already using $$, I think (TMP="`g.tempfile pid=$$`"). Is this
what you mean? Added $PROG, thanks.

It is easier to read, if instead of

output=$OUTPUT"_toflip"
you do
output=${OUTPUT}_toflip
or
output="${OUTPUT}_toflip"

Is the 1st one error prone or only "not nice"?

Is any of the 2 you recommend better? I'll correct my script
accordingly.

you probably want to use "sort -n" instead of "sort" so you don't get
1
13
2
20
etc.

In my case it doesn't matter - I only need to put identical words one
after another to filter out only 1 instance of each of them with uniq.

asis=`cat $TMP.cat_asis`
asis=`echo $asis | sed 's/ /,/g'`
probably hit the limitied size cap for a shell variable? (4096 chars?)
Use a tmp file.

Hmm, $asis is an input in the line 129:

v.extract -t layer=$LAYER input=$INPUT list=$asis output=
$OUTPUT"_leaveasis"

list= has to be a single, long string of numbers separated with ",". So
even if I avoid hitting the 4096 chars limit of a bash variable by
doing all in a TMP file, I will finally have to pass it to "v.extract
list=" as a one string, which will make it fail if the string is
longer than 4096 (is my thinking correct?).

A possible workaround would be to to convert long, continous sets
like eg. 1,2,3,4,5,...,100 into 1-100 and so on to save space. Is there
an easy way of doing it?

for a in $start_stop
do
..
done

make it easier to follow by indenting the inner part of the loop by a
few spaces.

see also v.out.ascii.db (wiki add-ons) and v.in.garmin (complex awk+tac
vector ascii format flipping to count vertices) scripts.

Thank you very much for all the hints. I really appreciate your help.

Best,
Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

(attachments)

v.flip_11 (4.86 KB)

[Maciej_Sieczka3]

Hi,

v.flip 1.2 attached.

On Tue May 16 01:55:07 CEST 2006 Hamish wrote:

Maciek wrote:

> I see. I don't do any maths on coordinates, I only use awk to select
> particular lines from v.out.ascii output and pipe them into another
> file, in a given order, so I should be on the safe side here.
>
> Is it possible to estimate what treshold should be enough? 0.0001,
> else???

So the coordinates haven't moved and should line up exactly. Thus
a tresh of 0.0 should catch them, but as a general rule floating point
numbers are of finite precision so it is usually better to test if
(a1-a2 < 1e-15) or so.

But this is mostly academic, anything smaller than a centimeter should
probably be snapped and your original value of 0.01 should be fine.

OK, thanks. I'll just put thresh=0.0001 then, at all events.

(unless this is a lat/lon location &/or your units are not meters!)
This means your module "touches the data" and isn't a fully reversable
proceedure, which may not be desired.

Do you think I should prevent the script from being run in a latlong
location? Unprojected XY too?

> >It is easier to read, if instead of
> >
> >output=$OUTPUT"_toflip"
> > you do
> >output=${OUTPUT}_toflip
> > or
> >output="${OUTPUT}_toflip"
>
> Is the 1st one error prone or only "not nice"?
>
> Is any of the 2 you recommend better? I'll correct my script
> accordingly.

all work, just cleaner to use. Quoting the whole thing only matters if
you have special characters in the map name, which are illegal anyway.
Hopefully then you get an informative GRASS error instead of a cryptic
bash error.

So I'll try to stick to

output="${OUTPUT}_toflip"

Hopefully I changed them all.

What about such as

foll="-"$1

within the awk code? Should they also be changed to something better?

> >asis=`cat $TMP.cat_asis`
> >asis=`echo $asis | sed 's/ /,/g'`
> >probably hit the limitied size cap for a shell variable? (4096
> >chars?) Use a tmp file.
>
> Hmm, $asis is an input in the line 129:
>
> v.extract -t layer=$LAYER input=$INPUT list=$asis output=
> $OUTPUT"_leaveasis"
>
> list= has to be a single, long string of numbers separated with ",".
> So even if I avoid hitting the 4096 chars limit of a bash variable
> by doing all in a TMP file, I will finally have to pass it to
> "v.extract list=" as a one string, which will make it fail if the
> string is longer than 4096 (is my thinking correct?).

ok. maybe better to use an SQL query then where= cat is not flip_list?
Don't know how to specify that. v.select doesn't have op=not, maybe
need v.overlay? If only flipping a few of several thousand lines you
may have trouble.

> A possible workaround would be to to convert long, continous sets
> like eg. 1,2,3,4,5,...,100 into 1-100 and so on to save space. Is
> there an easy way of doing it?

don't know.

I think I solved the problem, lines 128-137. I took care to handle any
possible combination of "," and "-" lists. Time will show :).

> Thank you very much for all the hints.

You already had it working, which is the hard part. A lot of this is
just tricks to make the code simpler & easier to catch errors.

Without your hints it would be harder. Thanks again.

The only thing missing I'd like to add is a datatable copy from the
original file to the flipped one. Should be easy, only it's too late to
do it now.

Also I want to send most of the messages into /dev/null.

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

(attachments)

v.flip_12 (5.32 KB)

[H_B]

> A possible workaround would be to to convert long, continous sets
> > like eg. 1,2,3,4,5,...,100 into 1-100 and so on to save space. Is
> > there an easy way of doing it?
>
> don't know.

I think I solved the problem, lines 128-137. I took care to handle any
possible combination of "," and "-" lists. Time will show :).

tr ',' '\n'
grep '-'
tr '-' ' '
seq $1 $2
cat single_list seq_lists > cat_lists
sort -n | uniq

?

Also I want to send most of the messages into /dev/null.

be careful of masking error messages.

nothing new, but many of these hints are listed here:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/SUBMITTING_SCRIPTS?rev=HEAD

Hamish

[Maciej_Sieczka3]

On Thu, 18 May 2006 16:30:33 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

> > A possible workaround would be to to convert long, continous sets
> > > like eg. 1,2,3,4,5,...,100 into 1-100 and so on to save space.
> > > Is there an easy way of doing it?
> >
> > don't know.
>
> I think I solved the problem, lines 128-137. I took care to handle
> any possible combination of "," and "-" lists. Time will show :).

tr ',' '\n'
grep '-'
tr '-' ' '
seq $1 $2
cat single_list seq_lists > cat_lists
sort -n | uniq

?

I don't understand how to use it instead of my approach. I tried to,
but I don't get it. Sorry :(. Anyway, it is not critical. Good I have
something working anyway :).

> Also I want to send most of the messages into /dev/null.

be careful of masking error messages.

Good point. Is there a way to only let warnings and errors get
through while masking other messages? My v.flip outputs several
terminals full of them.

nothing new, but many of these hints are listed here:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/SUBMITTING_SCRIPTS?rev=HEAD

I read it first. I'm doing my best not to ask anything not explained
there, to my understanding.

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

[H_B]

> > Also I want to send most of the messages into /dev/null.
>
> be careful of masking error messages.

Good point. Is there a way to only let warnings and errors get
through while masking other messages? My v.flip outputs several
terminals full of them.

all warnings and errors are sent to stderr. So you can redirect stdout
to "> /dev/null" without masking them. Not a total solution, but should
help. Noisy modules should consider a change to -v verbose mode flag or
moving non-interesting messages to G_debug().

Hamish

[Maciej_Sieczka3]

On Sun, 21 May 2006 17:55:53 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

> > > Also I want to send most of the messages into /dev/null.
> >
> > be careful of masking error messages.
>
> Good point. Is there a way to only let warnings and errors get
> through while masking other messages? My v.flip outputs several
> terminals full of them.

all warnings and errors are sent to stderr. So you can redirect stdout
to "> /dev/null" without masking them. Not a total solution, but
should help. Noisy modules should consider a change to -v verbose
mode flag or moving non-interesting messages to G_debug().

Hamish, All,

Thanks, this helped for all modules I use besides v.patch and v.clean.
They must be of this "noisy" kind you mention. Is there a way to mask
their output letting errors through only?

"&>/dev/null" masks both errors and messages completely - so no good.

But ">&1> /dev/null", as well as ">&2> /dev/null", almost does what I
need - ie. most of the v.patch output is filtered out (compare [1], [2])
and errors *are* let through, but I don't understand what exactly is
happening (though I know 1 is stdout, 2 is stderr) and if I'm not doing
anything "bad". ?

[1] Regular v.patch output:

$ v.patch input=cieki04,cieki05 output=cieki06
Patching file cieki04
Patching file cieki05
Building topology ...
372 primitives registered
Building areas: 100%
0 areas built
0 isles built
Attaching islands:
Attaching centroids: 100%
Topology was built.
Number of nodes : 207
Number of primitives: 372
Number of points : 0
Number of lines : 372
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0
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.

[2] same command, output at least partially masked:

$ v.patch input=cieki04,cieki05 output=cieki06 >&1> /dev/null
Patching file cieki04
Patching file cieki05
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.

P.S.
Once I understand this all I'll make a patch for SUBMITTING_SCRIPTS to
include information on how to safely prevent script from being
over-verbose.

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

[Maciej_Sieczka3]

Guys,

I really read all I could on the net and nowhere I found an explanation
why would

$ v.patch input=cieki04,cieki05 output=cieki06 >&1> /dev/null
as well as
$ v.patch input=cieki04,cieki05 output=cieki06 >&2> /dev/null

result in the output being reduced to:

[1]

Patching file cieki04
Patching file cieki05
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.

instead of a much more verbose, when v.patch is called normally:

[2]

Patching file cieki04
Patching file cieki05
Building topology ...
372 primitives registered
Building areas: 100%
0 areas built
0 isles built
Attaching islands:
Attaching centroids: 100%
Topology was built.
Number of nodes : 207
Number of primitives: 372
Number of points : 0
Number of lines : 372
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0
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.

Needless to say, as normal "> /dev/null" doesn't any help in case of
v.patch and v.clean output, I like [1] more than [2] and would like to
use ">&1> /dev/null" in my script to reduce v.patch and v.clean
verbosity, while leaving them able to issue warnings and errors still.

On the other hand, since I really don't understand why/how it works, I
don't want to cause any troubles to other eventuall users of my script,
in case it turns out be not portable/buggy/else in circumstances I
don't realize.

Could anybody knowledgable tell me if redirecting like ">&1> /dev/null"
is any wrong? Moreover, how it works anyway? I just tried it by luck
and it turned out to produce a nice result, that's all I know.

Looking forward to any hints from you.

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

[Maciej_Sieczka3]

On Tue, 23 May 2006 21:47:37 +0200
Maciek Sieczka <werchowyna@epf.pl> wrote:

Needless to say, as normal "> /dev/null" doesn't any help in case of
v.patch and v.clean output, I like [1] more than [2] and would like to
use ">&1> /dev/null" in my script to reduce v.patch and v.clean
verbosity, while leaving them able to issue warnings and errors still.

OK, user error. "> /dev/null" works as expected, ">&1> /dev/null" or
">&2> /dev/null" don't do any magic difference actually, in spite of
what I claimed. All the confussion comes from my too numerous trial and
error late at night, trying to filter out v.clean and v.patch output (to
no avail), which print to stderr things that should go stdout instead.

Sorry for the mess, still new to bash and coreutils, but learning :).

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

[Huidae_Cho]

Maciek,

FYI, "> /dev/null 2>&1" will suppress stderr messages as well as stdout while
"2>&1 > /dev/null" won't.

Check this page: http://geni.ath.cx/unix.html#toc6

Huidae Cho

On Tue, May 30, 2006 at 11:53:48PM +0200, Maciek Sieczka wrote:

On Tue, 23 May 2006 21:47:37 +0200
Maciek Sieczka <werchowyna@epf.pl> wrote:

> Needless to say, as normal "> /dev/null" doesn't any help in case of
> v.patch and v.clean output, I like [1] more than [2] and would like to
> use ">&1> /dev/null" in my script to reduce v.patch and v.clean
> verbosity, while leaving them able to issue warnings and errors still.

OK, user error. "> /dev/null" works as expected, ">&1> /dev/null" or
">&2> /dev/null" don't do any magic difference actually, in spite of
what I claimed. All the confussion comes from my too numerous trial and
error late at night, trying to filter out v.clean and v.patch output (to
no avail), which print to stderr things that should go stdout instead.

Sorry for the mess, still new to bash and coreutils, but learning :).

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

[Maciej_Sieczka3]

On Tue, 30 May 2006 17:19:53 -0500
Huidae Cho <grass4u@gmail.com> wrote:

Maciek,

FYI, "> /dev/null 2>&1" will suppress stderr messages as well as
stdout while "2>&1 > /dev/null" won't.

Check this page: http://geni.ath.cx/unix.html#toc6

Thanks Huidae! Nice.

The origin of my problem was that v.clean sends all it's output to
stderr instead of stdout, so real warnigs and errors are mixed with
normal output.

v.clean is very verbose and I would like to prevent it from filling my
screen with tones of output when called from a script, on one hand, yet
on the other I can't send all it's output to /dev/null as I want to
keep warnings and errors visible.

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

[Wolf]

On Wed, 31 May 2006, Maciek Sieczka wrote:

v.clean is very verbose and I would like to prevent it from filling my
screen with tones of output when called from a script, on one hand, yet
on the other I can't send all it's output to /dev/null as I want to
keep warnings and errors visible.

Then you will have to use grep. so do
v.clean |& grep 'ERROR\|WARNING'

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

[H_B]

which print to stderr things that should go stdout instead.

data -> stdout (e.g. d.where)
messages -> stderr
errors/warnings -> stderr

by making "messages" use G_message() we can potentially turn them off
with an enviro variable without turning off errors/warnings.

Hamish

[Maciej_Sieczka3]

On Wed, 31 May 2006 09:31:12 +0300 (EEST)
Wolf Bergenheim <wolf+grass@bergenheim.net> wrote:

On Wed, 31 May 2006, Maciek Sieczka wrote:

> v.clean is very verbose and I would like to prevent it from filling
> my screen with tones of output when called from a script, on one
> hand, yet on the other I can't send all it's output to /dev/null as
> I want to keep warnings and errors visible.

Then you will have to use grep. so do
v.clean |& grep 'ERROR\|WARNING'

Does anybody know other keywords I should let through?

Thanks Wolf!

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/