[GRASS-dev] [GRASS GIS] #2230: 'g.region -p' writes new WIND file, causes race condition for parallel jobs

[GRASS GIS]

#2230: 'g.region -p' writes new WIND file, causes race condition for parallel jobs
----------------------+-----------------------------------------------------
 Reporter:  hamish    |       Owner:  grass-dev@…              
     Type:  defect    |      Status:  new                      
 Priority:  normal    |   Milestone:  6.4.4                    
Component:  Default   |     Version:  svn-develbranch6         
 Keywords:  g.region  |    Platform:  Linux                    
      Cpu:  x86-64    |  
----------------------+-----------------------------------------------------

Comment(by glynn):

 Replying to [ticket:2230 hamish]:

 > In tracking down some strangeness I've just noticed that 'g.region -p'
 or 'g.region -g' writes out a new (unchanged) WIND file whenever it runs.

 It does this whenever it runs without the -u flag.

 One problem is that printing and setting are not mutually exclusive, i.e.
 you can both modify and print the current region. For example, the command
 {{{
 g.region -p res=10
 }}}
 will set the resolution to 10 units, write the modified region to the WIND
 file (or the region named by $WIND_OVERRIDE), and print the updated
 region.

 Other problems are:

  * The region is adjusted (by G_adjust_Cell_head3) before writing it, so
 the WIND file may actually be changed by running g.region with no
 arguments (or just with -p/-g).

  * The region may not even be read from the WIND file (or the region named
 by $WIND_OVERRIDE). If GRASS_REGION is set, the region will be read from
 that variable, but writes still go to WIND or $WIND_OVERRIDE.

 In short, simply skipping the G_put_window() call based upon which
 arguments are given (other than -u) would constitute a change to existing
 behaviour. You can't assume that the updated region will be identical to
 the previous region based solely upon which arguments are given.

 I think that the issue is essentially that people don't realise that
 g.region always sets the region unless -u is given. Even without any
 options which explicitly modify the region, it uses $GRASS_REGION if that
 is set, and adjusts the region before writing it. IOW, "g.region -p"
 doesn't "print the region", it "sets and prints the region"; "g.region
 -pu" prints (and only prints) the region.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2230#comment:2>
GRASS GIS <http://grass.osgeo.org>