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

Nikos Alexandris nikos.alexandris at felis.uni-freiburg.de
Sun Mar 7 19:20:00 EST 2010

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.


> > 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

Sorry if I insist so much about this,

More information about the grass-user mailing list