When exiting from the qgis GRASS shell, qgis overwrites ~/.grassrc6

[cgsbob]

When a GRASS command does not have any arguments, the gui to the command is displayed...but not in the new GRASS shell. The old GRASS shell did work this way.

[cgsbob]

I just tried this:

<il_rugginoso> cgs_bob: try this:
<il_rugginoso> open the grass plug-in
<il_rugginoso> and the shell
<il_rugginoso> on linux, and the trunk qgis
<il_rugginoso> write export GRASS_GUI="tcltk"
<il_rugginoso> and give the command you want
<il_rugginoso> if it work I can implement that quickly

It does not work :-(

Btw, I made this priority major because most grass users would expect the command gui to be displayed when a GRASS command has no arguments.

[cgsbob]

I decided to get brave and dive into the QGIS code :-) I know...my changes are very basic.

Anyways...I changed src/plugins/grass/qgsgrassshell.cpp so that I'm able to get the gui when I start a GRASS command without any arguments and I set the GIS_LOCK to the process id, so I can run GRASS' d.* commands.

Index: src/plugins/grass/qgsgrassshell.cpp
===================================================================
--- src/plugins/grass/qgsgrassshell.cpp (revision 10746)
+++ src/plugins/grass/qgsgrassshell.cpp (working copy)
@@ -102,10 +102,11 @@

     // Set shell program enviroment variables
     env << "GRASS_MESSAGE_FORMAT=";
-    env << "GRASS_UI_TERM=1";
+    // env << "GRASS_UI_TERM=1";
     env << "GISRC_MODE_MEMORY";
     env << "PS1=GRASS > ";
     env << "TERM=vt100";
+    env << "GIS_LOCK=$$";
     terminal->setEnvironment(env);

     // Look & Feel

Maybe I should submit a separate ticket and suggest that the GRASS Shell should have a configuration file that would allow GRASS power users to set up their own GRASS environment?

[rugginoso]

I think the shell must be only a terminal, for the gui of commands, you can use the other modules of the grass plug-in.

[cgsbob]

Replying to rugginoso:

I think the shell must be only a terminal, for the gui of commands, you can use the other modules of the grass plug-in.

Do you mean the grass gui that is defined by *.qgm? What about the grass commands that do not have a *.qgm file?

I think that most users of the shell are users who needs to access the many parameters of a command that are hidden by the qgis-grass gui. Sure, you can type v.generalize and answer about 20 questions before v.generalize can start. Or you can type v.generalize in the shell and see the grass gui for v.generalize along with all of its parameters and just fill out the information needed. Which method would you use?

Taking away the command gui is like going back to pre grass 6 (ok, so I exaggerate a bit here). I know with a few environment variables the grass shell can have the command gui. So, why not do it?

[pcav]

This is not what grass-qgis plugin was made for: the idea here is to present the user with a simplified set of options. In case you need more flexibility, we can always write a more complex module, with all the parameters to be filled (or with pre-set options). Having the full GUI of grass does not make sense here: if you want to use the grass GUI you better use grass directly. Furthermore, in this case QGIS would also depend on a whole lot of other software, which would make packaging (especially for windows) much more difficult. I suggest you to fill wishes for the commands for which you want more options available, and we can try to write them.

[cgsbob]

Replying to pcav:

This is not what grass-qgis plugin was made for: the idea here is to present the user with a simplified set of options. In case you need more flexibility, we can always write a more complex module, with all the parameters to be filled (or with pre-set options).

The grass-qgis plugin is also for the more advanced qgis user. Why not have an Advance user button that would enable the grass gui? All it takes to enable the grass gui is a little extra code that just sets a few grass environment variables:

export GRASS_PYTHON=python
export GRASS_TCLSH=tclsh
export GRASS_WISH=wish
unset GRASS_UI_TERM

Having the full GUI of grass does not make sense here: if you want to use the grass GUI you better use grass directly. Furthermore, in this case QGIS would also depend on a whole lot of other software, which would make packaging (especially for windows) much more difficult. I suggest you to fill wishes for the commands for which you want more options available, and we can try to write them.

Since most users will have this extra software (especially if you are a linux user or OSGEO4W users who have also loaded grass), I don't think it should make packaging difficult. I could imagine that logic can be added to test for these software component. If they exist, the grass gui should be enabled (see the little code block above).

In any case, I'll add the code block above to the wiki for those advanced qgis users :)

[rugginoso]

Fixed in r11118.

[cgsbob]

I am not able to get to a GRASS> prompt. Looking at the code, it appears that you assume that grass is installed in the /usr tree. Well, grass on my system is installed in /usr/local.

So, I changed the code like this:

Index: src/plugins/grass/qgsgrassshell.cpp
===================================================================
--- src/plugins/grass/qgsgrassshell.cpp (revision 11120)
+++ src/plugins/grass/qgsgrassshell.cpp (working copy)
@@ -83,7 +83,7 @@
   QStringList env("");
   QStringList args("");

-  QString shellProgram = QString("/usr/bin/grass%1%2").arg(QgsGrass::versionMajor()).arg(QgsGrass::versionMinor());
+  QString shellProgram = QString("/usr/local/bin/grass%1%2").arg(QgsGrass::versionMajor()).arg(QgsGrass::versionMinor());

   terminal->setShellProgram(shellProgram);
   env << "TERM=vt100";

Now the QGIS GRASS Shell starts and another problem appears. Executing the first grass command w/o argument closes the QGIS Grass Shell. Reopening the QGIS Grass Shell and running the same command now opens up the grass gui. At this point, the QGIS GRASS Shell functions the same as the GRASS Shell.

[rugginoso]

The first issue is resolvable in some ways, maybe looking for GRASS_PREFIX and calling Init.sh directly.
The second issue is stranger... It shouldn't crash the first time nor open the gui the second time.
Here it works as follows:
* Opening the grass shell is displayed the grass prompt
* Calling a command without options shows the GUI
* Calling a command with the options executes the command and the output is displayed as normal into the shell.
Could you provide more info?
As usual, thank you for your feedback :D

[rugginoso]

First issue (find the grass executable) should be fixed in r11123.

[cgsbob]

Replying to rugginoso:

First issue (find the grass executable) should be fixed in r11123.

Thank you for fixing the first issue. As for the second issue...I solved that one too :) There was a problem with one of the Grass Addons (GIPE) that messed up some of the wxpython code in grass. When I removed it, I no longer have the QGIS GRASS Plugin crash.

So I just compiled r11123 and with the grass path solved and the grass shell crash solved, I've been able to test further and find that there are other problems :(

So, here are the steps I took to demonstrate the problem:

* Opening the grass shell displays the grass prompt
* Calling a command without options shows the old tcltk GUI (GRASS_GUI not being honored)
* Calling a command with the options executes the command and the output is displayed normally into the shell.
* Ending the grass shell by clicking the Close Button ends grass gracefully

I have also tried to end the grass shell by typing CTRL-D and noticed that the last line in ~/.grassrc6 file has been changed from:

GRASS_GUI: wxpython

to

GRASS_GUI: text

With this change native GRASS will start up in text mode.

I would think that this ticket can be closed if you can figure out a way to find the grass command and have the QGIS GRASS Shell honor the GRASS_GUI settings in ~/.grassrc6 and not modify it.

Thank you for adding these enhancements to the grass shell!

[rugginoso]

Yes, I've found the problem: the startup script ($GISDATA/etc/Init.sh) make some cleanups when closing (see the line 1012 in grass64). It copy the session rc which is normally located in /tmp/grass6-$USER-$PID to the user one which is located in ~/.grassrc6.
One solution could be rename ~/.grassrc6 to something other and at the and rename it back (as done with lock file). This is a dirty solution, other ideas?

[cgsbob]

Replying to rugginoso:

Yes, I've found the problem: the startup script ($GISDATA/etc/Init.sh) make some cleanups when closing (see the line 1012 in grass64). It copy the session rc which is normally located in /tmp/grass6-$USER-$PID to the user one which is located in ~/.grassrc6.
One solution could be rename ~/.grassrc6 to something other and at the and rename it back (as done with lock file). This is a dirty solution, other ideas?

I'm not a C++ programmer, but I noticed that the line:

env << "GISRC_MODE_MEMORY";

Does that mean that ~/.grassrc6 will not be touched? I searched around and found that GDAL also uses GISRC_MODE_MEMORY (see line 818 in  https://svn.osgeo.org/gdal/trunk/gdal/frmts/grass/grass57dataset.cpp and I know it doesn't touch my ~/.grassrc6 file. So, maybe there is something in the link above that might help you?

[pcav]

AFAIK this applies to OSX, right?

[cgsbob]

Replying to pcav:

AFAIK this applies to OSX, right?

I am using the good ol' Ubuntu Hardy Heron on an X86_64. I just tried the steps shown in  https://trac.osgeo.org/qgis/ticket/1680#comment:13 on qgis r12280 and got the same results (GRASS_GUI is not set so the old tcltk gui is shown and ~/.grassrc6 is modified so that GRASS_GUI is set to text...see a pattern here?)

[lutra]

Hi,

the problem described in comments # 13 and # 17 is confirmed (r12907 under ubuntu): when using the qgis GRASS shell and exiting from it with "ctrl-d" or with "exit" (so, not closing the entire qgis GRASS toolbox), the file ~/.grassrc6 is always rewritten as

GISDBASE: /home/gio/Desktop/qgis_sample_data/grassdata

LOCATION_NAME: alaska

MAPSET: demo

GRASS_GUI: text

(instead of leaving GRASS_GUI: tcltk or GRASS_GUI: wx)

In any case the title of this ticket is no more the right one, so I'll change it.

[rblazek]

I have done something in r12919 too much work for nothing.