Created by Aleksey Nogin (ayn2@cornell.edu) on Sunday, August 16, 1998 12:12:23 PM PDT Additional Details : Currently Mozilla still uses ~/.netscape/ directory for its config files, although ~/.mozilla/ may seem more appropriate. Authors of different "brands" of Mozilla may want to have their programs to use separate directories and users may also want to use different versions of Mozilla with different config files. I wrote a patch (it is derived from the patch by Dan McGuirk <djm@indirect.com>) that adds a new run-time option -configdir <directory> that allows to specify a config subdirectory different from ".netscape" and also allows to change the compiled in default by changing one line of the ocode instead of hunting for all these hardcoded strings through all the sources. I am trying to keep the patch up-to-date with the current CVS sources and you should always be able to find them (divided into files according to modules) at ftp://ftp.cs.cornell.edu/pub/nogin/mozilla/

*** Bug 464 has been marked as a duplicate of this bug. ***

Ramiro was all over this, was going to check it in, and then some shit hit the fan at work and ? we need to get the patch again. Can you mail me a current version and I will try to check this in.

Reassigning to myself. I have the patch applied and ready to check in, however i have a few issues. I found some problems. For example, there was 'buf' variable that was not being initialized and causing asserts in xp_file.c Also, you rearranged a bunch of code. You moved the XtInitialize code around. You also changed where fe_InitializeGlobalResources() is called. There is also a problem when you give -config-dir a bogus directory or one that does not exist: mozilla-export -config-dir ~/foo is bad and we crash. There is also no documentation for -config-dir for --help. All of this hackery has got me thinking. We need a better solution for this stuff. The changes you made are a good start. Unfortunately, there already are so many config_dir global variables and other stuff in the xfe that confuses things. What I would like to have is a UnixFEConfig library which would contain all the functions associated with config dir and other. Im not sure if you are interested in working on such a library. It would be very useful - it could be used by the qt and gtk front ends as well. Here is what I would like to see: + All global/static 'config_dir' variables gone. + No config dir stuff in fe_GlobalData. Adding stuff to global data is bad. We should use the PREF_ api directly. + The environment is only checked once. In your current code you do getenv("HOME") everytime fe_GetConfigDir() is called. We should do this only once and store the results in a static variable. + More robust code. For example if you give a bogus option to -config-dir, it posts an FE_Alert() with an appropiate blurb.

Ok, i checked in the patches! Finally. Im really sorry that it took so long. There really is no good excuse. I can give you some lame ones, but the truth is I should have checked this code in as soon as you posted it. Anyway... I fixed the buf problem. There was a buf somewhere in there that was not being initialized and causing assert problems (and other random problems, probably). Ignore the fe_GlobalData comments above...I was tired when I wrote them and they have nothing to do with your code. I was confused with an unrelated prefs thing. I renamed the -configDir flag to -config-dir to be consistent with other flags. I still think it would be a interesting project to move all this config dir stuff to a nice happy library. Again, thanks for your help and patience. Marking fixed.

qa contact set to gerardok@netscape.com for review against current code base

I tried using the config-dir parameter with the apprunner on linux, but I couldn't make it work. On Feb 24th, asked developer to confirm if this code has been carried over to the new code base, but haven't got any answer yet. I suspect it's not applicable in the new code base. Status changed to Closed.

Status CLOSED is deprecated as per bug 169885

Status CLOSED is deprecated as per bug 169885

Re-resolving

verifying former CLOSED bugs