Unifying Shell Configuration Across Bash, Zsh, And Other Shells

Using different shell environments like Bash, Zsh, and others often leads to scattered configuration files. Variables, aliases, and functions end up duplicated across ~/.bashrc, ~/.zshrc, and more. This article explores strategies for centralizing configurations in a unified ~/.shellrc to simplify maintenance across shells.

The Problem of Scattered Configuration Files

Most Linux, BSD, and other Unix-based systems come with Bash as the default shell. Over time, users often customize their ~/.bashrc file to set custom prompts, aliases, variables, and functions. However, many users eventually switch to Zsh or another alternative shell for its additional features.

Upon switching shells, configurations don’t carry over. Users end up copying over bits and pieces from their ~/.bashrc to the new shell’s config file like ~/.zshrc. The same process repeats when switching to additional shells down the road.

Table of Contents

This leads to duplicated configurations scattered across various dotfiles. Keeping these in sync becomes tedious as changes need to be propagated across files. Debugging issues also becomes trickier when dealing with multiple config files.

Some key files that can end up with fragmented configurations:

~/.bashrc
~/.bash_profile
~/.zshrc
~/.profile
/etc/profile

Rather than managing independent configs, the concept of a unified ~/.shellrc aims to centralize settings in one place that all shells can source.

Introducing a Centralized ~/.shellrc

The ~/.shellrc file serves as a single source of truth that can be sourced by all login shells. This central dotfile handles common configurations such as:

Environment variables
Shell options
Aliases
Functions
Prompts

With all shells loading ~/.shellrc, changes only need to be made in one place. Variables, functions, and aliases are set centrally rather than duplicated across files.

Shell-specific dotfiles like ~/.bashrc and ~/.zshrc can override ~/.shellrc settings as needed. But the bulk of common configuration is handled in one spot.

This strategy prevents scattering configurations across random files. The ~/.shellrc approach greatly simplifies maintenance compared to traditional shell dotfiles.

Setting Up a Central ~/.shellrc

The first step is actually creating a ~/.shellrc file. Simply create an empty file using:

$ touch ~/.shellrc

Populate ~/.shellrc with configurations, similar to what you may currently have in ~/.bashrc or ~/.zshrc:

# Set environment variables
export EDITOR=vim

# Generic shell aliases
alias ll='ls -alh'

# Shell prompt customization
PS1="\u@\h $ "

Then source ~/.shellrc from the shell-specific dotfiles like ~/.bashrc. Add this to ~/.bashrc:

# Source centralized configs
if [ -f ~/.shellrc ]; then
  . ~/.shellrc
fi

And in ~/.zshrc:

# Source centralized configs 
if [ -f ~/.shellrc ]; then
  source ~/.shellrc
fi

This will load ~/.shellrc settings in all shells. Modifications only need to happen in one place from now on.

Unifying Prompt Customization

Customizing the prompt is one of the most common shell configurations. PS1 controls the Bash prompt while Zsh uses PROMPT. These can be set directly in ~/.shellrc:

# Generic PS1/PROMPT
PS1="\u@\h \w $ "
PROMPT="\u@\h \w $ "

But certain shells allow additional prompt formats like right-aligned text via RPROMPT. In that case, it’s better for ~/.bashrc and ~/.zshrc to override PROMPT/PS1 after sourcing ~/.shellrc:

# ~/.shellrc
PS1="\\u@\\h \\w $ "
RPROMPT=""

# ~/.bashrc
if [ -f ~/.shellrc ]; then
   . ~/.shellrc
   RPROMPT="|$(date +%H:%M)|" # Override in bashrc  
fi

# ~/.zshrc
if [ -f ~/.shellrc ]; then
  source ~/.shellrc 
  PROMPT='%B%1~%b %(!.#.$) ' # Override prompt in zshrc 
fi

This allows shell-specific prompt formats while keeping the defaults unified in ~/.shellrc.

Sharing Functions Between Shells

Reusable functions can be defined in ~/.shellrc and used across shells:

# Helper function to run sudo if needed
sudo-cmd() {
  if [[ $(id -u) -ne 0 ]]; then
    sudo "$@"
  else 
    "$@"
  fi
}

However, some functions may not be portable due to shell-specific syntax. Bash and Zsh have their own extensions and style preferences.

Writing portable functions requires avoiding bashisms and zshisms. Stick to POSIX sh compatibility with common syntax like $( ) instead of backticks.

For example, use standard [[ ]] instead of Bash [[ [[ ]] ]] or Zsh [[ ]] built-ins. Test portability in each shell before relying on ~/.shellrc functions globally.

In some cases, it makes sense for ~/.bashrc and ~/.zshrc to override functions after loading ~/.shellrc:

# ~/.shellrc
koopa() {
  echo "Default implementation"  
}

# ~/.zshrc 
if [ -f ~/.shellrc ]; then
   source ~/.shellrc
   koopa() {
     echo "Override in Zsh"
   } 
fi

This provides a central default in ~/.shellrc while allowing customizations per shell.

Setting Environment Variables

Environment variables are often scattered across ~/.profile, ~/.bashrc, ~/.zshrc, and more. This can cause inconsistencies:

# ~/.profile
export EDITOR=nano

# ~/.bashrc  
export BROWSER=firefox

# ~/.zshrc
export EDITOR=vim

The ~/.shellrc centralizes control of environment variables:

# ~/.shellrc
export EDITOR=vim
export BROWSER=firefox

However, some environments may need overrides. Bash and Zsh source different files on login. So ~/.bash_profile or ~/.zprofile may override after loading ~/.shellrc:

# ~/.bash_profile
if [ -f ~/.shellrc ]; then 
   . ~/.shellrc
fi

export LANG=C # Override LANG in Bash

Zsh counterparts like ~/.zprofile can customize the environment further too. This achieves consistency while providing a way to tweak settings per shell.

Dealing with Shell-Specific Configurations

For the most part, ~/.shellrc can handle general preferences across shells. But some things like completion styles and key bindings remain shell-specific.

It’s best to keep these configurations in their respective dotfiles instead of forcing ~/.shellrc unification:

# ~/.bashrc
bind 'set completion-ignore-case on'

# ~/.zshrc 
bindkey -e  # Emacs key bindings

Additionally, certain plugins and power tools are shell-specific. For example, Oh My Zsh in Zsh or Bash-it in Bash. It’s okay to source these directly in shell dotfiles:

# ~/.zshrc
source ~/.oh-my-zsh/zshrc # Keep OMZ config separate

# ~/.bashrc
source ~/.bash_it/bash_it.sh # Source Bash-it plugin

The key is balancing unification with practicality. Keep general preferences in ~/.shellrc but allow exceptions when shells diverge.

Maintaining Portability Between Systems

A chief benefit of ~/.shellrc is portability. This single file configures preferences across systems without needing to propagate changes.

However, some caveats include:

Usernames may differ across systems, avoid hardcoded references
Use standard sh syntax, not all systems have Bash/Zsh
Handle differences in macOS vs Linux paths
Test compatibility with sh, Bash, Zsh, and fish if possible

Also keep software installations in mind. For example:

# Conditional dotfile loading  

if type python &> /dev/null; then  
  . ~/.pythonrc
fi

if type node &> /dev/null; then
  . ~/.noderc  
fi

This ensures the expected software is actually available before sourcing additional config files. Overall, maintaining cross-system portability requires planning but enables consistent preferences across environments.

Conclusion and Recommendations

The fragmented nature of shell configuration files leads to maintainability headaches. Centralizing dotfile preferences via ~/.shellrc and shell-specific .rc files streamlines things tremendously.

Managing configurations in one unified place prevents duplication across ~/.bashrc, ~/.zshrc, and related files. Changes also propagate to all shells by modifying ~/.shellrc in just one spot.

Environment variables, functions, aliases, and prompt settings are prime candidates for ~/.shellrc unification. However, certain shell-specific settings should remain separate as needed.

With a sound dotfile structure, developers can focus more on actual work rather than fighting inconsistent configs. The principles covered here demonstrate keeping preferences in sync doesn’t have to be painful.

Some additional ideas for improving workflows:

Version control dotfiles with Git
Automate dotfile bootstrapping across systems
Split functions/aliases into plugins loaded on-demand
Sync configs across machines with remote dotfile hosts

What other techniques have you found helpful for managing shell environments? Dotfiles may seem mundane but have an outsized impact on daily productivity and efficiency.