[GRASS-dev] where to store GRASS settings: GISRC and wx settings

[Hamish]

Markus Metz wrote:
> In general I think it is a good idea to have all the
> settings and other stuff, e.g. grass-addons,

sorry to complicate the discussion, but fwiw the meaning of the
grass-addons dir is another unresolved issue we'lll need to deal
with-- it started life as something user defined to concatenate
onto $PATH, but now is also used like --prefix=, and so we have
this confusing hybrid of both.


> in one single folder, and not scattered around. But that is a
> design change already implemented in grass7.
> 
> Since there seems to be a majority to not introduce these
> changes to 6.x, I will revert the changes I did to 6.5 and also
> change some backports from trunk to 6.x regarding the file
> where wxGUI settings are stored, i.e. 6.x shall use .grasswx6
> as in pre-6.4.2.

to clarify what I meant & why-

I'm not so concerned about ~/.grasswx6, as that's quite new
and not as likely to be accessed by user's own scripts,
literature, experience & expectations where to find things when
things break (1,000 archive posts telling people to remove/edit
that file if it gets broken), etc.


What I am really really concerned about is changing ~/.grassrc6,
which is a core file that has stood like that since 6.0, 6.2,
6.3.0, 6.4, and 'til now all our hard efforts to maintain
compatibility through all the grass 6 line has been unwaivering*.


[*] A notable compatibility exception was the vector/dbln file
format which we necessarily had to change to allow for spaces
in path names, but I think the solution we finally came to
helped the transition happen without any ill effects or anyone
really noticing.

While not really relevant beyond the "it was like that in 6.x for
historical reasons" understanding, fwiw I'd mention ~/.grassrc5
and for earlier grass 4 "~/.grassrc" have been there since the
1990s, and perhaps the 1980s too? since stability = discipline *
time, and one of our great strengths is time. whenever we cut
old roots and reset that clock to 0 it's a great loss to one of
our core assets.


thanks,
Hamish