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 <[EMAIL PROTECTED]>

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

_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to