DaveS wrote:Trio, I tried this a while ago with Firefox/SM 1.1.18 but ran into a problem. The directory .mozilla ends up being shared by both Firefox and SM. This causes occasional security errors to be thrown up by 1.1.18.
Having Firefox and SeaMonkey share a directory is possible, but is generally not a good idea. How well it works depends on which versions are installed.
Mozilla products use two directories: the application directory and the profile directory.
The application directory is where the product itself and the libraries it uses reside. There will be a wrapper script in /usr/bin that will find the actual executable (firefox-bin or seamonkey-bin), set up the environment, and run it.
The profile directory is where the user's files reside. Bookmarks, themes, add-ons, config files and the cache reside here. This is why you can upgrade to a new version conveniently: the upgrade replaces files in the application directory, but doesn't touch the profile directory.
The problem with having multiple products share the same profile directory lies in versions. Some add-ons work in one product but not another. Some add-ons work in either product, but may not work in differing versions.
For instance, SeaMonkey 1.1X uses the XPIInstall framework. Firefox 2.X and higher, and SeaMonkey 2.l0 and greater use the Gecko Toolkit. Add-ons written for one don't work in the other.
In addition, Firefox up to 2.X, and SeaMonkey through 1.1X store bookmarks in a bookmarks.html file. Firefox 3+ and SeaMonkey 2+ shifted to using an SQLite database. FF 2.x and SM 1.1X wont read FF 3.X/SM 2.X bookmarks files, and vice versa. (It's possible to export the SQLite databse to HTML readable by older browsers, and import older bookmarks.html files into more recent browsers, but it's a whole different can of worms.
It's probably better to use separate profile directories, and doing so is fairly simple.
FF and SM include a Profile Manager that can create, manipulate, and remove profiles. To get to it, start the application as
This will display a box that lists profiles the program knows about. From here, you can select a profile, or click the button that says Manage Profiles.
From the Manage screen, you can create a new profile, rename an existing one, or delete a profile. (You can choose the delete the profile entry from the list the product looks at but leave the directory it points to, or delete the profile entry and the directory is points to and the files in it.)
When you choose the Create Profile function, you are asked for a name to give the profile, which defaults to Default User. You can also use Choose Folder to specify
where you want the profile to be created. In SeaMonkey, for instance, the default is /root/.mozilla/<something>.Default-User, but you can specify a different location. The name of the profile directory will match what you specified as the profile name.
Doing this makes in convenient to have separate profiles for each product, and more than one profile for the same product. (On Windows, for instance, I have a "production" profile for Firefox 3.6, and another customized for development, which loads a different set of add-ons.)
You can select which profile to use from the Profile Manager, or you can do so by specifying the profile you want to use on the command line, like
I have custom shortcuts on Windows where the shortcut property specifies the profile. You can do something similar on Linux.
Obviously, doing this breaks some sharing between apps. What you do depends on what you want to share.
Bookmarks are easy between compatible versions. In SM 1.1X and FF2, there's a reference you can set to specify the bookmarks file you want to use. In FF 3+/SM 2, that poreference is no longer available, but you can create a hard link of the desired bookmarks file into the new profile directory. (If versions are not compatible, like trying to share between two products, one of which uses bookmarks,html and the other uses places.sqlite, it's possible but trickier. I'll discuss that in another post if you want to know.)
You probably
don't want to share add-ons, because of version issues. Better to install desired add-ons separately into each product.
I believe can share the cache, but this is done from within the program, by specifying where you want the cache put. You can go into abouit:config in the product, and create a preference called
browser.disk.cache.parent_directory, and set the value of the preference to where you want the cache to be. I'm experimenting with putting the cache into /dev/shm, the Linux tmpfs file system. Stuff there is in buffers in RAM or in swap, and never hits the hard drive. (It also goes away on reboot, but I don't care.)
______
Dennis