Vaclav Petras wrote:
> 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).
bash scripts "exec" g.parser in the current process, in place of bash.
g.parser then re-executes the calling script with the option values
stored in environment variables. If g.parser fails, the script never
gets re-executed, and the exit status of g.parser is the exit status
of the process which was originally running the script.
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.
If you consider GRASS modules as being the Python equivalent of GRASS
API functions in C, then there isn't an inconsistency. Rather than
explicitly checking for a map, we rely upon whatever tries to use
generating a fatal error if it doesn't exist.
If you want to directly check for the existence of a map, use
grass.script.find_file() (a wrapper around g.findfile, which in turn
is a wrapper around G_find_file2(), which is what C code would use for
that purpose).
--
Glynn Clements <glynn@gclements.plus.com>