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 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
