The basic thing is to put your dot files under version control. When you use a new machine, check them out.
git clone https://github.com/saterhater/home.git
In case the machine doesn't have your version control tool, you might want to at least download a read-only version. Github automates this; if you use different hosting that doesn't provide such a feature, make the generation of the zip file a commit hook.
wget -O - https://github.com/saterhater/home/archive/master.zip | unzip -
As for the content of the files, you'll obviously need to make sure that they're portable. There's no magic recipe for that, just a few tips.
- Make sure to test your files under older versions of the shells, not just the ones you're using. I keep chroots with older Debian releases to get a range of versions of various software (my personal configuration should in principle work with bash 1.14 and zsh 2.5, though I haven't used versions that are that old in years).
- If you rely on any uncommon dependency, check it into your VCS, or write some automation to download it.
- If you want to make use of some feature when it's present, but keep a fallback if it's absent, test for the feature rather than testing the version number. It's more robust (some systems might have a nightly build, for example).
You can share some things between bash and zsh, mostly aliases and some functions. Key bindings and prompt settings aren't shareable. Bash completion functions can be used with non-ancient versions of zsh. If you have some code that makes use of the automatic splitting and globbing of unquoted variables that zsh doesn't perform, you can run
emulate -L ksh to make zsh switch to ksh compatibility mode for the duration of a function; make
emulate an alias to
: if the shell isn't zsh (you can test the presence of the