[GRASS-user] 6.4 vs 7.0

GRASS GRASS user
1

Hi to all.

I have some scripts which perfectly work in GRASS 6.4 whereas in GRASS
7.0 they give problems.
Here some examples:

r.mapcalc 'grid1=rand(1,10)' #works in GRASS 6.4;
## in 7.0 I need:
r.mapcalc expr='grid1=rand(1,10)' –overwrite

echo "UPDATE polyNoTopology \
SET label='poly$a' WHERE cat=$index" | db.execute ##works in GRASS
6.4; in 7.0 I need:
echo "UPDATE polyNoTopology \
SET label='poly$a' WHERE cat=$index" | db.execute in=-

echo "5,3" | v.in.ascii out=point fs="," cat=0 --o # works perfectly
in 6.4 but not in 7.0
## in 7.0 I have to create a file (perhaps, is there a better way?)
echo "5,3">coord
v.in.ascii input=coord out=point fs="," cat=0 --o

Is there a rule of thumb for this... new syntax ? (e.g. “no pipe at all”?)
Do I have to test version (g.version) in all my (bash) scripts ?
Is there a workaround, perhaps any tips and tricks, to avoid modify
all my scripts in order to work in 6.4 **and** in 7.0 ?
(ok: perhaps python scripting should be a solution; I'm trying...)

Thanks

--
Paolo

2

Paolo Craveri wrote:

I have some scripts which perfectly work in GRASS 6.4 whereas in GRASS
7.0 they give problems.
Here some examples:

r.mapcalc 'grid1=rand(1,10)' #works in GRASS 6.4;
## in 7.0 I need:
r.mapcalc expr='grid1=rand(1,10)' –overwrite

echo "UPDATE polyNoTopology \
SET label='poly$a' WHERE cat=$index" | db.execute ##works in GRASS
6.4; in 7.0 I need:
echo "UPDATE polyNoTopology \
SET label='poly$a' WHERE cat=$index" | db.execute in=-

echo "5,3" | v.in.ascii out=point fs="," cat=0 --o # works perfectly
in 6.4 but not in 7.0
## in 7.0 I have to create a file (perhaps, is there a better way?)
echo "5,3">coord
v.in.ascii input=coord out=point fs="," cat=0 --o

Is there a rule of thumb for this... new syntax ? (e.g. “no pipe at all”?)
Do I have to test version (g.version) in all my (bash) scripts ?
Is there a workaround, perhaps any tips and tricks, to avoid modify
all my scripts in order to work in 6.4 **and** in 7.0 ?
(ok: perhaps python scripting should be a solution; I'm trying...)

The 7.0 version of r.mapcalc uses G_parser(); an expression can be
given on the command line using expression= (or any unique
abbreviation). However, as this is the first parameter, it can be
omitted, *provided* that the expression doesn't have the form
"variable=value". Inserting a space before the "=" is sufficient, so
e.g.:

  r.mapcalc 'grid1 = rand(1,10)'

will work in both 7.0 and older versions.

For modules which require e.g. in=- in 7.0 and don't accept it in 6.x,
you could try using in=/dev/stdin, although this may not work on all
platforms.

Alternatively, you could file bug reports against the 6.4 modules for
not accepting "-" as an input filename. There really isn't any excuse
for not implementing this feature.

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

3

On Sun, Jan 17, 2010 at 12:05 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Paolo Craveri wrote:

I have some scripts which perfectly work in GRASS 6.4 whereas in GRASS
7.0 they give problems.

...

echo "UPDATE polyNoTopology \
SET label='poly$a' WHERE cat=$index" | db.execute ##works in GRASS
6.4; in 7.0 I need:
echo "UPDATE polyNoTopology \
SET label='poly$a' WHERE cat=$index" | db.execute in=-

echo "5,3" | v.in.ascii out=point fs="," cat=0 --o # works perfectly
in 6.4 but not in 7.0
## in 7.0 I have to create a file (perhaps, is there a better way?)
echo "5,3">coord
v.in.ascii input=coord out=point fs="," cat=0 --o

...

Alternatively, you could file bug reports against the 6.4 modules for
not accepting "-" as an input filename. There really isn't any excuse
for not implementing this feature.

Perhaps it could become the default behaviour in 7 to read from stdin
(d.execute etc.) to mimick the behaviour of G6-d.execute?

Markus

4

Hi Paolo,

I have some scripts which perfectly work in GRASS 6.4
whereas in GRASS 7.0 they give problems.

that is to be expected. Compatibility is not guaranteed between major
versions. this frees us up to fix things which we were locked into
before.

Here some examples:

r.mapcalc 'grid1=rand(1,10)' #works in GRASS 6.4;
## in 7.0 I need:
r.mapcalc expr='grid1=rand(1,10)' –overwrite

r.mapcalc in GRASS 7 now uses the GRASS parser (for --help, --quiet, etc)
so now behaves like all other GRASS modules.

If you use "
GRASS_OVERWRITE=1 \
  r.mapcalc "result = map * 4

it will work on both versions. Important is the space around the "=" so
that GRASS's parser doesn't try and match a "result=" option. See the
r.mapcalc man page in GRASS 7 for details. GRASS_VERBOSE can be passed
as an enviro variable as well.

echo "UPDATE polyNoTopology \
  SET label='poly$a' WHERE cat=$index" | db.execute ##works
in GRASS 6.4; in 7.0 I need:
echo "UPDATE polyNoTopology \
  SET label='poly$a' WHERE cat=$index" | db.execute in=-

here "input=" has been set to be a required input. AFAIU this is so the
option appears on the first tab of the module GUI window ("Required").
I've complained about that before, so won't repeat myself, but what is
really needed IMO is a new item added somewhere to help order the GUI
sections so these GUI-at-the-expense-of-the-CLI hacks can be avoided.

echo "5,3" | v.in.ascii out=point fs="," cat=0 --o # works
perfectly in 6.4 but not in 7.0
## in 7.0 I have to create a file (perhaps, is there a
better way?)
echo "5,3">coord
v.in.ascii input=coord out=point fs="," cat=0 --o
Is there a rule of thumb for this... new syntax ?

in general using "-" as the input filename should tell it to read from
stdin instead of a real file. If that doesn't work then it's a bug.
Support for this is slowly being added to grass 6.5svn, just because it
should, regardless of what happens with option=Required or no.
(AFAIK input=- for stdin is an old unix tradition)

(e.g. “no pipe at all”?)

that wouldn't be very nice.

Do I have to test version (g.version) in all my (bash) scripts ?

If you intend to use them over multiple (major) versions, then Yes!

(ok: perhaps python scripting should be a solution; I'm trying...)

fwiw, that won't help much if the module options change. I guess the
verbose and overwrite stuff will be automatically handled by the grass.py
package, and command line options passed as a single expression won't be
treated like an option, so yes actually python could help in some cases.
just be sure to use the grass.package and not just make system() calls.

note that grass 7 is still in development and will continue to change,
so any scripts written for gr7 today might not work tomorrow or in the
final release.

Hamish

5

Markus Neteler wrote:

> Alternatively, you could file bug reports against the 6.4 modules for
> not accepting "-" as an input filename. There really isn't any excuse
> for not implementing this feature.

Perhaps it could become the default behaviour in 7 to read from stdin
(d.execute etc.) to mimick the behaviour of G6-d.execute?

That's not good for the GUI, where the module won't have a stdin
(ideally, it will have been closed; if not, the module will hang,
waiting to read from whatever its stdin happens to be).

Requiring e.g. input=- has the advantage that GUI users are unlikely
to do this accidentally; choosing "-" via the file selector would
require that you have a file named "-" somewhere.

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

6

Hamish wrote:

> echo "UPDATE polyNoTopology \
> SET label='poly$a' WHERE cat=$index" | db.execute ##works
> in GRASS 6.4; in 7.0 I need:
> echo "UPDATE polyNoTopology \
> SET label='poly$a' WHERE cat=$index" | db.execute in=-

here "input=" has been set to be a required input. AFAIU this is so the
option appears on the first tab of the module GUI window ("Required").
I've complained about that before, so won't repeat myself, but what is
really needed IMO is a new item added somewhere to help order the GUI
sections so these GUI-at-the-expense-of-the-CLI hacks can be avoided.

Regardless of how it affects the GUI, I really can't accept that
having to add " in=-" is a significant burden.

IMHO, we should just fix 6.4's db.execute to accept in=-. Allowing it
provides forward-compatibility with 7.0 without breaking backward
compatibility with 6.3/6.4-SVN. Ditto for v.in.ascii and anything else
which is capable of reading from stdin.

If it helps, I could add G_open() and G_fopen() which accept "-" as a
valid filename (meaning stdin for read, stdout for write; obviously
read-write access won't work with "-").

> (ok: perhaps python scripting should be a solution; I'm trying...)

fwiw, that won't help much if the module options change. I guess the
verbose and overwrite stuff will be automatically handled by the grass.py
package, and command line options passed as a single expression won't be
treated like an option, so yes actually python could help in some cases.
just be sure to use the grass.package and not just make system() calls.

grass.script.run_command() etc can't handle 6.x's r.mapcalc. However,
grass.script.mapcalc() can (it passes the expression via stdin rather
than on the command line), although it doesn't offer control over the
overwrite, quiet and verbose options. That could be changed, though.

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