[GRASS-user] Calling GRASS scripts from GRASS C modules

GRASS GRASS user
1

Greetings

I’m building a segmentation and statistical image analysis module (in C) and I want to call a grass script. Is it possible inside a GRASS C module? If so, How can I do that? (or can anyone give me an online example=

Thanks
Best regards,
Monica

2

On Mon, Mar 21, 2011 at 5:03 PM, Monica Buescu
<monicabuescu1985@gmail.com> wrote:

Greetings
I'm building a segmentation and statistical image analysis module (in C) and
I want to call a grass script. Is it possible inside a GRASS C module? If
so, How can I do that? (or can anyone give me an online example=

You can use the popen() function. See for example:

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/r.statistics/o_median.c#L22

Markus

3

Markus Neteler wrote:

> I'm building a segmentation and statistical image analysis module (in C) and
> I want to call a grass script. Is it possible inside a GRASS C module? If
> so, How can I do that? (or can anyone give me an online example=

You can use the popen() function. See for example:

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/r.statistics/o_median.c#L22

Note that code which uses system() or popen() tends to be error-prone,
particularly on Windows. I would strongly discourage anyone from using
either system() or popen() in new code. Significant effort went into
eliminating the use of these functions from 7.0, with good reason.

G_spawn() and G_spawn_ex() provide a more robust interface, but
require more code in the case where you need to communicate with the
child process via a pipe (see lib/db/dbmi_client/start.c for an
example).

7.0 has G_popen_{read,write}, which do most of the work for you, but
these haven't been back-ported to 6.x yet.

Alternatively, you can use a temporary file rather than a pipe for
communicating with the child process.

--
Glynn Clements <glynn@gclements.plus.com>

4

On Tue, Mar 22, 2011 at 3:26 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...

7.0 has G_popen_{read,write}, which do most of the work for you, but
these haven't been back-ported to 6.x yet.

I have compared the two lib/gis/popen.c files. Is backport as "easy" as
adding the GRASS 7 functions in 6 to also keep the old G_popen() and
G_pclose() for backward compatibility?

Markus

5

Hi

In my case I’m using 6.4.1 from September 2010 (before the major changes in WxPython GUI) and I want to run it in Windows. So, am I able to use that?

Thanks
Monica

On Tue, Mar 22, 2011 at 7:45 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Tue, Mar 22, 2011 at 3:26 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
…

7.0 has G_popen_{read,write}, which do most of the work for you, but
these haven’t been back-ported to 6.x yet.

I have compared the two lib/gis/popen.c files. Is backport as “easy” as
adding the GRASS 7 functions in 6 to also keep the old G_popen() and
G_pclose() for backward compatibility?

Markus

6

Markus Neteler wrote:

> 7.0 has G_popen_{read,write}, which do most of the work for you, but
> these haven't been back-ported to 6.x yet.

I have compared the two lib/gis/popen.c files. Is backport as "easy" as
adding the GRASS 7 functions in 6 to also keep the old G_popen() and
G_pclose() for backward compatibility?

Yes.

But the existing G_popen() and G_pclose() functions should either be
removed or replaced with:

  FILE *G_popen(const char *cmd, const char *mode)
  {
      return popen(cmd, mode);
  }
  
  int G_pclose(FILE *ptr)
  {
      return pclose(ptr);
  }

There's no reason to (attempt to) provide our own implementations of
these functions, particularly when the Windows version is completely
broken.

Note that G_popen() has already been removed from 6.5, with the code
changed to use popen() instead. This still suffers from the usual
issues with trying to reliably construct a shell command, but it
avoids the G_popen()-specific bugs.

In 7.0, all references to popen() have been removed, and the only use
of system() is in D_close_driver(), to execute a shell command
specified by the GRASS_NOTIFY environment variable.

--
Glynn Clements <glynn@gclements.plus.com>

7

Monica Buescu wrote:

> > 7.0 has G_popen_{read,write}, which do most of the work for you, but
> > these haven't been back-ported to 6.x yet.
>
> I have compared the two lib/gis/popen.c files. Is backport as "easy" as
> adding the GRASS 7 functions in 6 to also keep the old G_popen() and
> G_pclose() for backward compatibility?

In my case I'm using 6.4.1 from September 2010 (before the major changes in
WxPython GUI) and I want to run it in Windows. So, am I able to use that?

If you don't need to communicate with the child process via a pipe,
you can use G_spawn() or G_spawn_ex(). These provide similar
functionality to system() but without the shell getting in the way
(using the shell creates problems if filenames or other arguments
contain spaces or other characters which are significant to the
shell).

If you need to communicate via a pipe, you can either use G_spawn_ex()
and manage the pipe yourself (see lib/db/dbmi_client/start.c for an
example), or use popen(). Don't use G_popen(); the Unix version is
practically the same as popen() anyhow, and the Windows version is
completely broken.

--
Glynn Clements <glynn@gclements.plus.com>

8

On Wed, Mar 23, 2011 at 5:14 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

> 7.0 has G_popen_{read,write}, which do most of the work for you, but
> these haven't been back-ported to 6.x yet.

I have compared the two lib/gis/popen.c files. Is backport as "easy" as
adding the GRASS 7 functions in 6 to also keep the old G_popen() and
G_pclose() for backward compatibility?

Yes.

But the existing G_popen() and G_pclose() functions should either be
removed or replaced with:

   FILE \*G\_popen\(const char \*cmd, const char \*mode\)
   \{
       return popen\(cmd, mode\);
   \}

   int G\_pclose\(FILE \*ptr\)
   \{
       return pclose\(ptr\);
   \}

There's no reason to (attempt to) provide our own implementations of
these functions, particularly when the Windows version is completely
broken.

Note that G_popen() has already been removed from 6.5, with the code
changed to use popen() instead. This still suffers from the usual
issues with trying to reliably construct a shell command, but it
avoids the G_popen()-specific bugs.

So I will replace the existing popen.c file in 6.4.svn with the code above.
It goes into 6.4.2 then.

In 7.0, all references to popen() have been removed, and the only use
of system() is in D_close_driver(), to execute a shell command
specified by the GRASS_NOTIFY environment variable.

ok.

Markus