I've accumulated Bash configuration over time and recently organized it into a small dotfiles repository. It mainly contains my .bashrc, .inputrc, .bash_profile, a modular .bashrc.d/ directory, and a small installation script. The setup can be installed with either Ansible or the standalone install script. I'd appreciate feedback from people who maintain their own dotfiles, especially regarding Bash and Linux best practices, portability concerns, questionable choices, or ways to improve the organization. The configuration is intentionally fairly minimal and may be more deployment-focused than optimized for an elaborate interactive shell.
4 Answers
A common approach is to keep aliases in a separate file, such as .bash_aliases, and source it from .bashrc. You can even add a helper command that runs alias and writes the output back to that file, making it easy to save newly created aliases. The same general organization works well for other shells too—separate files for aliases, key bindings, exports, functions, history, and plugins.
If globstar is enabled, you may also want to consider extglob and possibly direxpand, depending on how the rest of the configuration handles filename expansion. They can make advanced globbing and completion behavior more consistent, but only enable them if you actually rely on those features.
Since this seems deployment-oriented, I’d give the history configuration some extra attention. A function that builds HISTIGNORE from grouped patterns can make the list easier to maintain and lets you omit routine commands, directory navigation, noisy Git commands, and arguments that may contain passwords, tokens, or secrets. Treat that as a starting point rather than a universal list, since history filtering can behave differently depending on the command format. Also, avoid exporting ordinary Bash-only variables unless child processes actually need them.
I agree about keeping regular shell variables unexported. Exporting them unnecessarily can leak configuration into child processes and makes the environment harder to reason about.
This is nicely organized and avoids a lot of unnecessary complexity. It looks particularly suitable for consistent deployment across machines rather than for turning an interactive terminal into a heavily customized environment.
I use a similar structure with Zsh: a small entry file points to a config directory containing separate files for aliases, bindings, exports, functions, history, and plugins. It keeps the main shell configuration much easier to navigate.