I use many applications written using Mozilla technologies, these applications support the so called profiles allowing users to run multiple instances of same application but using different “configuration” environments.
As developer I use profiles to test extensions without compromise the integrity of my main env.
Running multiple profiles is described in million of places so I don’t annoy you but I describe my own solution based on a bash script that hides details.
Creating bash scripts to run separated application profiles requires only a bit of shell programming experience but it is a repetitive task and can be boring when you need to run different version for example firefox 2 and firefox 3, you manually must write the same script modifing only the application path.
My approach allow to configure applications to run in a single file and then create automatically the necessary scripts.
Suppose you want to run a new songbird profile, using my script you can write:
The sb script creates a new separated profile on a configured directory with a default name, but suppose you need a second (third and so on) songbird profile you can pass your preferred name
dave@dafihome:~$ sb testVSW
Now you need to test also Firefox 2.x and Firefox 3.x profiles, simply write
dave@dafihome:~$ ff20 testVSW dave@dafihome:~$ ff30 testVSW
So you have three separated profiles with same name testVSW, how they don’t clash? The real name created by script uses the application prefix so the directories names are
Do you need Komodo 4.4.x and 5.x profiles? Again
dave@dafihome:~$ ko4 dave@dafihome:~$ ko5 italian-locale
The names sb, ff20, ff30, ko4 and ko5 are configured in ‘~/.moz_profilerc’
The file format is very similar to fstab and contains three columns describing applications.
The first column contains the type of application.
At this time it can be set to mozapp or komodo, this is necessary because mozilla apps uses MOZ_NO_REMOTE env variable to run separated profiles instead komodo uses KOMODO_USERDATADIR.
The second column is the script name user runs from command line (and is also the prefix added to profile directory names)
The third column contains the application absolute path
Below is shown my configuration
mozapp ff30 /opt/devel/mozilla/ff30/firefox mozapp ff30en /opt/devel/mozilla/ff30en/firefox # ff20 refers to installed firefox mozapp ff20 /usr/bin/firefox
mozapp flock /opt/devel/mozilla/flock/flock mozapp komp /opt/devel/mozilla/kompozer/kompozer
mozapp sb /opt/devel/mozilla/Songbird/songbird mozapp mccoy /opt/devel/mozilla/mccoy/mccoy
komodo ko5 /opt/devel/mozilla/ko5/bin/komodo komodo ko4 /opt/devel/mozilla/Komodo-Edit-4/bin/komodo
Profile destination directories
I group profiles by extension, for example inside ViewSourceWith source directory I have a ‘profile’ subdirectory where all profiles are written, this is specified in ‘~/.moz_profilerc’
# Directory where profiles will be created, inside profile present on current directory profileDir $PWD/profile # If true create profileDir silently, otherwise generate error profileDirCreateSilently false
It is possible to write all profiles inside a specific directory setting profileDir
Scripts destination directories
The scripts sb, ff20, ff30, ko4, ko5 are symbolic links, they are generally created inside a directory present on $PATH env variable.
I prefer to add them inside /usr/local/bin (this should require to be root)
# Directory where links will be created, generally resides in env PATH linkDestDir /usr/local/bin
The script moz_profile.sh
All operations are done using the script moz_profile.sh that allows to edit configuration file and create applications scripts.
Editing configuration (it opens the editor set on $VISUAL or $EDITOR env)
dave@dafihome:~$ moz_profile.sh -e
dave@dafihome:~$ moz_profile.sh -c
This script greatly simplifies switching from profiles, obviously occupied disk space grows but after a profile is no more needed you can delete it without risks