Michael Barton wrote:
> I am probably missing something. But I guess I don't understand the
> advantage of using the modules available from this grass library over
> using normal Python functions to run a GRASS command. That is, the
> syntax for running a command here doesn't seem any easier--and maybe a
> shade more complicated than simply using subprocess.call for simple
> one-shot commands and subprocess.Popen for commands where you need to
> return stdout or stderr.
>
> Are there other benefits to using a grass library that I'm not
> understanding?
The idea is to avoid scripts all needing to include similar code.
The code examples aren't particularly good examples, as they all have
hard-coded literal option values. If you're running a command with
fixed options, then subprocess.call is straightforward. But most
practical scripts will be using Python expressions as option values,
so they will end up needing the equivalent of make_command. E.g.:
grass.make_command( "r.category",
map = map,
cats = cats )
versus:
subprocess.call(["r.category",
"map=%s" % map,
"cats=%s" % ",".join(map(str,cats))])
--
Glynn Clements <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
