On 02/02/15 13:48, Glynn Clements wrote:
Moritz Lennert wrote:
For now, I've added a warning that you should know what you are doing if
you want to use these calls.
Why not just use suitable examples, e.g. using subprocess.Popen()
(without shell=True), with the caveat that on Windows it won't work
for scripts, only compiled executables.
But what exactly is the problem with using subprocess.call with
shell=True ? Security issues ? Difficulties in calling shell scripts ?
AFAICT, it's just a wrapper around Popen.wait(), or ?
I've now replaced this with:
subprocess.Popen(['r.watershed', 'elevation=elevation',
'threshold=10000', 'stream=raster_streams'])
or would it be better with .wait():
import subprocess
subprocess.Popen(['r.watershed', 'elevation=elevation',
'threshold=10000', 'stream=raster_streams']).wait()
?
I guess this depends on what the programmer wants...
For C, it's somewhat harder, as there isn't a mechanism for executing
commands which is standard, simple, reliable and portable. GRASS'
G_spawn* functions mostly have the last 3 (other than not working for
scripts on Windows). fork()+exec*() isn't portable or particularly
simple, but is at least standard on POSIX systems. Windows doesn't
really have anything in that regard (you have to do the quoting
yourself, and the rules differ for executables and scripts).
I think that's why I don't think that we should fret too much about the
specfic examples here. The main argument in the whole section is that it
is possible to consider GRASS modules as an "API" in its own right of
which you can call the "functions" (aka modules) from any programming
language via system calls. The exact syntax of these calls are beyond
the scope of the document.
And even though within GRASS Python it should always be Popen(), maybe
there are situations out there where calling a module via call() is
justifiable...
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
