[GRASS-dev] New wiki page summarising GRASS APIs

[Moritz Lennert]

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