<div dir="ltr"><div><br><br>On Tue, Jun 2, 2015 at 6:34 AM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>><br>> On Tue, Jun 2, 2015 at 3:05 AM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>> wrote:<br><br>> > Perhaps interactive session (--text & --gui) should have the<br>> > check.<br>><br>> Definitely. IMHO there is no point in starting GRASS GIS as<br>> interactive session from within GRASS - only asking for troubles. Or<br>> is there any use case where this makes sense?<br><br></div>I cannot think of any but the issue might be how do we recognize we are in a session versus somebody just have some variables set in system environment and wishes to start GRASS in a regular way. Perhaps using GISRC rather then GISBASE to see if we are in a session?<br><div><br>> > If the check is present (even just for the interactive sessions), the<br>> > OSGeo4W version (and probably standalone winGRASS too) is going to break<br>> > (needs to be changed somehow).<br>><br>> Why does the OSGeo4W break? This is not clear to me.<br><br></div><div>Well, that's the part I'm not sure about. From the commits it seems that OSGeo4W sets GISBASE ahead because the compile time path recored in grass.py is wrong.<br><br>You can see `GISBASE=%OSGEO4W_ROOT%\apps\grass\grass-@VERSION@` in:<br><br><a href="https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/osgeo4w/env.bat.tmpl">https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/osgeo4w/env.bat.tmpl</a><br></div><div><br></div><div>Although there is nothing with GISBASE in:<br><br><a href="https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/env.bat">https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/env.bat</a><br></div><div><br></div><div>Perhaps forcing different GISBASE should be done using different variable such as GRASS_GISBASE? GISBASE would mean GISBASE of currently running session. GRASS_GISBASE would mean I wish to use use this path as GISBASE next time I start GRASS session. But I'm not sure if I like it. It could mess up the script on MS Windows a lot.<br></div><div><br>> > Moreover, this would disallow setting some<br>> > GISBASE to system for scripting purposes ("without starting explictly") and<br>> > then starting a standard session.<br>><br>> .. you mean in the non-interactive case.<br><br></div><div>No, I mean setting GISBASE into my system for convenient writing of scripts which use "without starting explicitly" paradigm and then starting standard session, interactive (--text, --gui) or non-interactive (--exec, GRASS_BATCH_JOB). Any check for GISBASE as a proof of already running session would disallow starting an actual session in this case (at least in interactive mode if check is implemented only for the interactive mode). Again, perhaps checking for GISRC rather then GISBASE is the way out.<br></div><div><br></div><div>Note that putting the variable into system environment is advantageous for the scripts because it leads to scripts without hardcoded paths which can be moved from machine to another. A lot of software, such as Java requires you to set some environmental variables to enable using in command line or in general.<br><br>However, in case of GRASS we can say that the best practive is to but the executable on path and query executable for GISBASE (which is for example needed for PYTHONPATH which is needed for import grass.script which is needed for setup.init call).<br></div><div><br>> > The issue with the current state is that you cannot run different version of<br>> > GRASS from a current session.<br>><br>> ... yes, luckily :-)<br>><br>> > More serious issue is that you cannot start<br>> > another version if you have GISBASE in your system environment for scripting<br>> > purposes (as mentioned above). The current behavior may also differ<br>> > depending on a platform.<br>><br>> Cannot we suggest to the user via test to remove that variable? Rather<br>> than overriding it?<br><br></div><div>Currently, as far as I understand, we are actually overriding it with OSGeo4W (in the bat script, not grass.py which then uses it). On Linux, it will be used. The warning would be always present with OSGeo4W.<br><br></div><div>Asking user to remove the variable would also mean that you would have to put that to your scripts (which use "without starting explicitly" paradigm). So maybe you wouldn't be required to set GISBASE but you would have to delete it. This goes against my ultimate goal which is to make "using GRASS modules from outside" easier.<br><br></div><div>But then again, perhaps the problem is that we check for a wrong variable. I will try to discuss it more in answer to Moritz.<br></div><div><br>> > I'm not really sure what were the original intentions but I would prefer to<br>> > switch the logic in r45576 and use GISBASE only if the path from compile<br>> > time does not exist. This allows to override current session (GISBASE set in<br>> > some way) but allows to supply the GISBASE when there is something wrong<br>> > with compile time path. I would use some advice because I don't know how<br>> > this works on Windows and Mac nor what grass.sh file is supposed to do.<br>><br>> I cannot comment yet on this unless I fully understand the issue (see<br>> questions above).<br>> Probably the pseudo-code should go into a trac page?<br><br></div><div>grass.py now has (pseudo-code):<br><br></div><div>if GISBASE in environment:<br></div><div>    current_gisbase = GISBASE path from environment<br></div><div>else:<br>    current_gisbase = GISBASE path set at compile time<br><br></div><div>According to mentioned commits and the env.bat.tmpl file it seems that OSGeo4W goes to the first case because the compile time path is wrong. Unfortunately, also in case of having GISBASE set in system to have it at hand (as some people do on Linux), the first case applies and you many end up in different version of GRASS then intended (GISBASE points to stable release but you explicitly started trunk).<br><br></div><div>I suggested using GISBASE from environment as fallback:<br><br>current_gisbase = GISBASE path set at compile time<br></div><div>if current_gisbase does not exist:<br><div>    if GISBASE in environment:<br></div>        current_gisbase = GISBASE path from environment<br><br>But I'm not sure how reliable "current_gisbase does not exist" could be.<br><br></div><div>In this email I also suggested GRASS_GISBASE variable:<br><br><div>if GRASS_GISBASE in environment:<br></div><div>    current_gisbase = GRASS_GISBASE path from environment<br></div>else:<br>    current_gisbase = GISBASE path set at compile time<br><br></div><div>This would nicely solve the OSGeo4W case (special variable for a special case), but I'm afraid it could also complicate the scripts (but perhaps not?).<br></div></div>