[GRASS-user] can I access mapset outside of grass, by using python?

[Nikos Alexandris]

Glynn,
thank you so much for sharing :-)

I understand that this "way" of using grass isn't recommended for (let
us say) beginners. Nevertheless, my aim was/is to put most of this
thread in a wiki-page because I consider it as very practical.

Before doing so I want to test more to look for "gaps" and ask for
possible problems. More below...


Νίκος wrote:
> > 1. Would you mind sharing in addition the way you change between
> > mapsets/locations? Do you start a new shell session after re-defining
> > somehow the variables LOCATION_NAME or/and MAPSET? Use just g.gisenv?

Glynn wrote:
> Use g.mapset.

Right!


> > Is there a way to lock-out all other versions of grass-modules from
> > being detectable when I am already inside a grass70 session?

> The grassXY scripts prepend the GRASS directories to PATH,
> LD_LIBRARY_PATH, etc. They won't remove any entries which are already
> there.
> 
> I only use the grassXY scripts if I actually need to test the startup
> process. To switch versions, I use the following script:

[...]

> Note: the above script needs to be "source"d; executing it won't work.

Didn't test that yet. Trying now...

.

The thing that troubles me most currently is: using normal grass
sessions you get entries recorded in
"/grassdb/location/mapset/.bash_history" while working with "pure" bash
shell entries go in "~/.bash_history".

- Merging existing "grass-bash_history(-ies)" with "bash_history" would
probably be NOT a good idea.

- Trying to separate (somehow) grass-commands history-entries and other
shell actions related to a specific grass-project (speak
grassdb/project/location/mapset) from other grass-projects or
non-grass-projects is, I think, non-sense.

So, when working on a project, it is best practice to stick with
grass-sessions?

Sorry if I insist so much about this,
Nikos