On 01/02/15 21:22, Vaclav Petras wrote:
On Sun, Feb 1, 2015 at 2:26 PM, Moritz Lennert <[email protected] <mailto:[email protected]>> wrote: On 01/02/15 12:29, Glynn Clements wrote: Pietro wrote: {{{ import os os.system('g.region rast=elevation') }}} and not subprocess: {{{ import subprocess subprocess.call('g.region rast=elevation', shell=True) # or subprocess.Popen('g.region rast=elevation', shell=True) }}} Concerning the pygrass Module API, may be we can use the shortcut version: Using subprocess.call() with shell=True is no better than using os.system(). Both should be avoided at all costs. The grass.script module provides a number of convenience functions which use grass.script.make_command() to generate the command's argument list from the function's argument list. Also, they use a version of subprocess.Popen() which has been wrapped to deal with some of Windows' idiosyncrasies. Just to be clear: the example on this wiki page shows just that it is possible to call any GRASS module from any language that allows system calls. It then goes on to introduce the scripting API to show how that eases things on the script writer since she doesn't have to deal with any idiosyncrasies. But if this causes too much opposition I can take it out or at least put a big warning of likes of "Don't use this ! Example code only." I suggest to use Bash example instead of Python one because this is how it is actually (also) used.
Well, there's no real syntax for a GRASS module call from Bash, you just do it, so the first example on the page can actually be considered a Bash example...
If some warning is needed, it probably applies to all, Bash, C system calls and Perl too.
Maybe I should just erase all examples, just leaving the information that you can call GRASS modules via system calls if you know what you are doing.
For now, I've added a warning that you should know what you are doing if you want to use these calls.
Do you consider a section for 3rd party APIs? Particularly I'm asking about spgrass in R (the same philosophy as grass.script for Python) and QGIS Processing (wrapper, limited functionality?, different philosophy).
Good idea. I just added a section linking to these two. I don't have much time these days to add anything else on them. So anyone who does, feel free.
Moritz _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
