bashrcd VS dotfiles

I moved to splitting my bashrc into multiple files and having my main bashrc source them from a ~/.bashrcd directory.

At heart it's a short snippet that just checks for existence and sources each file in the directory:

https://github.com/targaryen/bashrcd/blob/master/install/ins...

I added aliases to list/edit/remove entries from the .bashrcd directory and resource it. And a script I can call with a one-liner to edit bashrc on a new machine to add the sourcing and the helper aliases.

It'll load alphabetically so I can prefix entries with a number to specify load order (defaulting to 0100 so I don't need to specify this in the commands unless I explicitly changed them).

So the end result is that I can quickly edit or create a new bashrc entry by running 'ebrc entryname'. This opens ~/.bashrcd/0100--entryname in vi, and when it's saved it'll re-source so the add/change takes effect immediately.

Or 'lbrc' to list contents of the directory, or 'rbrc entryname' to remove ~/.bashrcd/0100--entryname

It's fairly simplistic but takes away most of the cognitive load of managing a complex bashrc.

Source: https://github.com/susam/dotfiles/blob/main/shrc#L381

I have a similar setup for my personal and project websites. Some similarities and differences:

* I use Linode VMs ($5/month).

* I too use Debian GNU/Linux.

* The initial configuration of the VM is coded as a shell script: https://github.com/susam/dotfiles/blob/main/linode.sh

* Project-specific or service-specific configuration is coded as individual Makefiles. This takes care of creatng An example: https://github.com/susam/susam.net/blob/main/Makefile

* The software is written in Common Lisp. In case of a personal website or blog, a static website is generated by a Common Lisp program. In case of an online service or web application, the service is written as a Common Lisp program that uses Hunchentoot to process HTTP requests and return HTTP responses.

* I use Nginx too. Nginx serves the static files as well as functions as a reverse proxy when there are backend services involved. Indeed TLS termination is an important benefit it offers. Other benefits include rate limiting requests, configuring an allowlist for HTTP headers to protect the backend service, etc.

I have something similar but a little more elaborate at my ~/bin to ensure that there isn't a severe loss of quality during the conversion: https://github.com/susam/dotfiles/blob/e434b7c/bin/xmp3

I follow a similar but handcrafted approach. I have a dotfiles repo with a setup script that automates the creation or deletion of all the symbolic links: https://github.com/susam/dotfiles/blob/master/setup

So what I do on any new system is just:

  git clone https://github.com/susam/dotfiles.git