Bug report #5644

GRASS integration should use private, not user's .grassrc6 file

Added by Markus Neteler almost 12 years ago. Updated about 8 years ago.

Status:Closed
Priority:Normal
Assignee:Victor Olaya
Category:Processing/GRASS
Affected QGIS version:2.4.0 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:15206

Description

Currently Sextante (1.5) is using the user's $HOME/.grassrc6 file.
This ruins the command line usage of GRASS afterwards:

grass64
Cleaning up temporary files ...
Starting GRASS ...
access: No such file or directory
ERRORE: LOCATION << /home/neteler/sextante/tempdata/grassdata/temp_location
        >> non disponibile

Solution: Simply set GISRC differently.

Here a solution derived from the GRASS-on-cluster usage page:

# Set the global grassrc file to individual file name
UNIQUE=`mktemp --dry-run`
MYTMP=`basename $UNIQUE`
VERSION=6
GISRC="$HOME/.grassrc$VERSION.$MYTMP" 
export GISRC

Also in case of QGIS/Sextante crashes, this would not touch the original GISRC of the user.

History

#1 Updated by Victor Olaya almost 12 years ago

  • Status changed from Open to Resolved

In windows, SEXTANTE runs its own batch script, which sets the gisrc file to a predefined one (sextante.gisrc) in the SEXTANTE user folder. In linux, instead, it just calls GRASS using the GRASS_BATCH_JOB variable. I have changed the behaviour in linux (change commited to r195), so the GISRC variable is set to that custom file as well.

I hope this solves the problem

#2 Updated by Giovanni Manghi over 11 years ago

  • Status changed from Resolved to Closed

I assume this can be closed, please reopen it if necessary.

#3 Updated by Markus Neteler over 11 years ago

  • Status changed from Closed to Reopened

Current SEXTANTE break the $HOME/.grassrc6 file as before, hence reopened:

[neteler@north ~]$ cat .grassrc6
GISDBASE: /home/neteler/.qgis//sextante/tempdata/grassdata
LOCATION_NAME: temp_location
MAPSET: user
DEBUG: 0
GRASS_GUI: text

As mentioned: it should not touch this file at all.

#4 Updated by Victor Olaya over 11 years ago

  • Status changed from Reopened to Feedback

Hi Markus

The current code runs this before actually calling GRASS

gisrc = SextanteUtils.userFolder() + os.sep + "sextante.gisrc"
os.putenv("GISRC", gisrc)
os.putenv("GRASS_MESSAGE_FORMAT", "gui")
os.putenv("GRASS_BATCH_JOB", GrassUtils.grassBatchJobFilename())

And then all edits are done on the sextante.gisrc file. The .grassrc6 file is not touched, as far as I have checked in the latest version. Is there any other way that file can change if not editing it directly ?(maybe running some GRASS commmand that edits it...).

thanks in advance for your help to fix this!

#5 Updated by Markus Neteler over 11 years ago

Try something along these lines:

# Set the global grassrc file to individual file name
MYGISRC="$HOME/.grassrc6.$MYUSER.`uname -n`" 

#generate GISRCRC
echo "GISDBASE: $HOME/grassdata" > "$MYGISRC" 
echo "LOCATION_NAME: $MYLOC" >> "$MYGISRC" 
echo "MAPSET: $MYMAPSET" >> "$MYGISRC" 
echo "GRASS_GUI: text" >> "$MYGISRC" 

# path to GRASS settings file
export GISRC=$MYGISRC

... then do the job.

#6 Updated by Markus Neteler over 11 years ago

I would also suggest:

os.putenv("GRASS_MESSAGE_FORMAT", "gui")
-> os.putenv("GRASS_MESSAGE_FORMAT", "plain")

(see http://grass.osgeo.org/grass64/manuals/variables.html for options)

#7 Updated by Markus Neteler about 11 years ago

Victor, what is the current state here?

#8 Updated by Victor Olaya about 11 years ago

Hey Markus,

I just had another look at that part, and what you suggest is exactly what SEXTANTE is doing. It creates a new gisrc file, and then sets GISRC to that file.

Could you please check that you still have the problem. The only difference between your suggested solution and the current one is the name of the file, but I guess that should not be a problem (unless GRASS refuses to use the name SEXTANTE uses for the file and reverts to the default .grassrc6)

Thanks!

#9 Updated by Markus Neteler about 11 years ago

Victor Olaya wrote:

Hey Markus,

I just had another look at that part, and what you suggest is exactly what SEXTANTE is doing. It creates a new gisrc file, and then sets GISRC to that file.

The behaviour is as before:
  • using QGIS 1.8 from Fedora repo, fetching Sextante 1.0.9 via plugin manager
  • slope calculation as example in QGIS-Sextante-GRASS
  • exit from QGIS
  • start current GRASS 6.4.svn:
grass64 
Cleaning up temporary files ...
Starting GRASS ...
access: No such file or directory
ERROR: LOCATION << /tmp/sextante/grassdata/temp_location >> not available

cat $HOME/.grassrc6 
GISDBASE: /tmp/sextante/grassdata
LOCATION_NAME: temp_location
MAPSET: PERMANENT
DEBUG: 0
GRASS_GUI: wxpython

--> The file has been overwritten again. Sextante should use e.g.
$HOME/.grassrc6.sextante

See also

#10 Updated by Victor Olaya about 11 years ago

- using QGIS 1.8 from Fedora repo, fetching Sextante 1.0.9 via plugin manager

oops, that might be a problem. We do no more work on SEXTANTE for 1.8. Since some time ago, the development version (which is now in the QGIS repo) can run only on QGIS master. The change in the API made backwards compatibility hard to mantain, so we are targeting just QGIS 2.0 now.

Not sure that that solves the problem, but the SEXTANTe version you are getting from the plugin manager is old, and it's not being updated now. I recommend you trying QGIS master.

Once 2.0 is out, we will release separate versions of SEXTANTe, but now you need QGIS master to run the latest developments. Sorry for that, and thanks again for your help!

#11 Updated by Markus Neteler about 11 years ago

While SEXTANTE from the QGIS 1.8 plugin manager may be old, it is the official one :-)

Well, I am not able to run a development version of QGIS on my systems since we are
in production... if you point me to the file where this is handled, I may see how
to fix it even for 1.0.9 (looks like a potentially trivial fix to me).

However, feel free to "wontfix" here, as you prefer.

#12 Updated by Victor Olaya about 11 years ago

Yes, I understand that a dev version is not fine in all environments...

You can find the code that handles that in here: GrassUtils.py

Tell me if you need me to do something else, and thanks again!

#13 Updated by Filipe Dias over 10 years ago

Is this still valid?

#15 Updated by Giovanni Manghi almost 10 years ago

  • Status changed from Feedback to Open

#16 Updated by Giovanni Manghi over 9 years ago

  • Project changed from 78 to QGIS Application
  • Category deleted (59)
  • Affected QGIS version set to 2.4.0
  • Crashes QGIS or corrupts data set to No

#17 Updated by Giovanni Manghi over 9 years ago

  • Category set to Processing/GRASS

#18 Updated by Markus Neteler about 9 years ago

Another report: OSGeo Live #1398 : QGIS's processing (sextante) toolbox hijacks grass's .rc file

#19 Updated by Jürgen Fischer about 9 years ago

Markus Neteler - wrote:

Another report: OSGeo Live #1398 : QGIS's processing (sextante) toolbox hijacks grass's .rc file

Processing runs GRASS commands via GRASS_BATCH_JOB through grass64. And it's GRASS' Init.sh that saves processing's temporary rc over the user's rc.

Is there a way around this or should we simply rename the user's rc before running grass64 and restore it afterwards?

#20 Updated by Markus Neteler about 9 years ago

AFAIK you can define the name like through a variable:

GISRC:
name of .grassrc6 file. Defines the system wide value while in a GRASS session.

(http://grass.osgeo.org/grass64/manuals/variables.html)

#21 Updated by Jürgen Fischer about 9 years ago

Markus Neteler - wrote:

AFAIK you can define the name like through a variable:

GISRC:
name of .grassrc6 file. Defines the system wide value while in a GRASS session.

(http://grass.osgeo.org/grass64/manuals/variables.html)

That's what it does (plus using GRASS_BATCH_JOB) - and the link in my previous comment points to the very line that copies that rc over the user's rc (AFAICS $GISRCRC is the user's rc if there is no "$HOME/.grassrc6.`uname -n`"). Perhaps it would be good to move the copy to the else branch of the following if.

#22 Updated by Alexander Bruy over 8 years ago

  • Status changed from Open to Feedback

Any news on this? As I can see from code Processing creates private gisrc file.

#23 Updated by Médéric RIBREUX about 8 years ago

  • % Done changed from 0 to 100
  • Status changed from Feedback to Closed
  • Resolution set to fixed/implemented

Hello, bug triage...

I can't reproduce it on QGIS 2.13 master with GRASS7 on Debian Stretch. File ~/.grass7/rc is untouched by QGIS which creates a temporary ~/.processing.gisrc7. There is the same code for GRASS6.4.

I am closing this bug which seems to be fixed by more than one user !

Also available in: Atom PDF