[GRASS-dev] Parser checking output maps but not input maps

Vaclav Petras wenzeslaus at gmail.com
Mon Jul 6 17:15:32 PDT 2015

On Mon, Jul 6, 2015 at 7:56 PM, Glynn Clements <glynn at gclements.plus.com>

> > > > is there some reason for GRASS parser not checking if the input map
> exists?
> > > > It checks if the output map exists and if it it does it ends
> execution with
> > > > an error.
> > >
> > > If an input map (or file) doesn't exist, you'll get an error when the
> > > module tries to open it.
> >
> > If I understand correctly, this applies only for C modules not Python or
> > Bash modules, right?
> For scripts which use g.parser for argument parsing, if G_parser()
> fails g.parser itself fails, which in turn causes the script to fail.
> Python scripts should normally terminate on an exception if a spawned
> command fails, whereas shell scripts normally ignore the status of any
> spanwed commands.

For Python this is ensured by checking "@ARGS_PARSED@" in g.parser output
in grass.script.core.parse() [1]. For Bash I have no idea how it is/was
done (e.g. in version 6).

However, my problem is that in C if you have an input map, you don't have
to check that whether it exists. While in Python you have to check if it
exists otherwise the first module (subprocess) you call with it will
unexpectedly fail. I hit this issue when I was trying to write
documentation for writing scripts and I wanted to do it the right way (as
opposed to hopping that some random script I pick in the source code
follows well the undocumented API).

The question now is if we want to fix the inconsistency in between writing
C and Python (and error reporting with overwrite). Or if we say that the
current state is good enough as long as it is documented and there is some
convenient function to check existence of a map. I don't think I exhausted
all options, so if somebody has an idea or is willing to implement
something, that would be great.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150706/33df6885/attachment.html>

More information about the grass-dev mailing list