[GRASS-dev] Python Scripting

[Michael Barton]

On Jul 16, 2008, at 1:28 AM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>>> 	subprocess.call([
>>> 		"v.extract",
>>> 		"input=%s" % os.getenv("GIS_OPT_INPUT"),
>>> 		"output=%s_%s" % (os.getenv("GIS_OPT_OUTPUT"), i),
>>> 		"type=point", "layer=1", "new=-1", "list=%s" % i])
>>
>> Glynn,
>>
>> How do subprocess.call and subprocess.Popen compare for running GRASS
>> commands from inside Python scripts? Is call easier than Popen in  
>> this
>> context?
>
> subprocess.call is a convenience function for the simplest case where
> you don't need to interact with the child process beyond waiting for
> it to finish; it's defined as:
>
> 	def call(*args, **kwargs):
> 	    """Run command with arguments.  Wait for command to complete,  
> then
> 	    return the returncode attribute.
> 	
> 	    The arguments are the same as for the Popen constructor.   
> Example:
> 	
> 	    retcode = call(["ls", "-l"])
> 	    """
> 	    return Popen(*args, **kwargs).wait()
>
> It behaves like system(), but without the shell (so you don't have to
> deal with /bin/sh syntax vs cmd.exe syntax, spaces and other shell
> metacharacters in argument values, etc).
>
> It's roughly equivalent to os.spawnvp(P_WAIT,...), which is deprecated
> in favour of the subprocess module. Most of the other os.* functions
> are similarly deprecated, except for the os.exec* family (for which
> the main use is executing g.parser).
>
> -- 
> Glynn Clements <glynn at gclements.plus.com>

This seems very handy for a lot of basic GRASS scipting, including  
replacing bash scripts with Python ones--something that I'd like to  
start on soon and would encourage anyone wanting to get experience in  
Python to try.

Michael