[GRASS-user] can I access mapset outside of grass, by using
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...
> > 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?
> 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
> 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