Re: [GRASS-dev] [GRASS-SVN] r65307 - grass/trunk/lib/init

2015-07-08 Thread Huidae Cho
Martin,

I think the following change has to be reverted because it breaks aliases
and custom prompts defined in ~/.grass7/bashrc. Currently, only
NAME=VALUE lines are parsed from this file in load_env().

Regards,
Huidae


On Thu, May 21, 2015 at 5:45 PM, svn_gr...@osgeo.org wrote:

 Author: martinl
 Date: 2015-05-21 14:45:19 -0700 (Thu, 21 May 2015)
 New Revision: 65307

 Modified:
grass/trunk/lib/init/grass.py
 Log:
 grass.py: don't overwrite environmental variables in bash_startup()


 Modified: grass/trunk/lib/init/grass.py
 ===
 --- grass/trunk/lib/init/grass.py   2015-05-21 21:01:15 UTC (rev 65306)
 +++ grass/trunk/lib/init/grass.py   2015-05-21 21:45:19 UTC (rev 65307)

...

 @@ -1443,9 +1449,7 @@
  path = os.path.join(userhome, .grass.bashrc) # left for backward
 compatibility
  if os.access(path, os.R_OK):
  f.write(readfile(path) + '\n')
 -if os.access(grass_env_file, os.R_OK):
 -f.write(readfile(grass_env_file) + '\n')
 -
 +
  f.write(export PATH=\%s\\n % os.getenv('PATH'))
  f.write(export HOME=\%s\\n % userhome) # restore user home path

  http://lists.osgeo.org/mailman/listinfo/grass-commit

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] what is the meaning of: Error reading raster data for row 239 of MASK

2015-07-08 Thread Glynn Clements

Moritz Lennert wrote:

 I don't know how to debug this...

Can you identify a repeatable test case?

If I could make it happen, I could debug it.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


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

2015-07-08 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev