DEV Community

Cover image for run.sh Diaries #5: Make It Yours – Forking, Tweaking & Extending the Setup
LazyDoomSlayer
LazyDoomSlayer

Posted on

run.sh Diaries #5: Make It Yours – Forking, Tweaking & Extending the Setup

#linux #webdev #programming

TL;DR
In this final post, I’ll show you how to take my Ubuntu WSL bootstrap and make it your own.

Whether you want to add dotfiles, set up Git identity, or install completely different tools, this structure makes it easy to fork, extend, and personalize.

Why Customization Matters

This project works for me, but you should own your environment.

My goal from the beginning was to make this:

  • Modular (each tool gets its own script)
  • Transparent (readable Bash, no black-box logic)
  • Easy to tweak (just edit configs or scripts)

This isn’t a framework, it’s a blueprint.

1. Add or Remove Packages

You can edit packages.conf to:

  • Add tools you always install (e.g. jq, htop, gh)
  • Remove things you don’t use (e.g. yazi, btop) 
SYSTEM_UTILS_APT=(
  wget curl jq htop
)

DEV_TOOLS_SNAP=(
  nvim
)
Enter fullscreen mode Exit fullscreen mode

These arrays are passed into helper functions from utils.sh, which handle install logic cleanly.

2. Add Your Own Scripts

To add new tooling (like Go, Deno, or Rust), follow this pattern:

  1. Create a new file like go-setup.sh
  2. Add install logic using apt, Snap, curl, or custom methods
  3. Append it to the SCRIPTS=(...) array in run.sh

Example:

readonly SCRIPTS=(
  ...
  "go-setup.sh"
)
Enter fullscreen mode Exit fullscreen mode

3. Include Dotfiles or Shell Config

Want to bootstrap your .bashrc, .tmux.conf, or .gitconfig?

You can:

  • Clone your dotfiles repo in a new dotfiles-setup.sh
  • Symlink them or append to existing configs
  • Set aliases, functions, or themes

This is also a good place to add default Git config, like:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
Enter fullscreen mode Exit fullscreen mode

4. Handle Secrets and Git Identity

Avoid committing private tokens or configs. Instead:

  • Keep a local ~/.local-setup.sh script with personal logic
  • Add .local-setup.sh to your .gitignore
  • Source it at the end of run.sh (if it exists) 
if [ -f "$HOME/.local-setup.sh" ]; then
  echo "Running local custom setup..."
  bash "$HOME/.local-setup.sh"
fi
Enter fullscreen mode Exit fullscreen mode

5. WSL-Specific Optimizations

Some tweaks worth adding if you run WSL full time:

  • Create a .wslconfig on Windows for better resource limits
  • Add mounts or performance tweaks in /etc/wsl.conf
  • Disable unnecessary services that don’t apply in WSL

You can even add a WSL check to run.sh:

grep -qi microsoft /proc/version && echo "Running under WSL"
Enter fullscreen mode Exit fullscreen mode

Fork It, Extend It, Own It

  • This whole project is meant to be cloned, forked, and hacked.
  • Start with mine, and make it match your exact stack and preferences.
  • If you build something cool from this, I’d love to see it.

Final Recap

Over the last 5 posts, you’ve seen how I:

  1. Automated my WSL Ubuntu setup from scratch
  2. Wrote modular Bash scripts with smart defaults
  3. Bootstrapped a full terminal dev stack
  4. Installed Node, Python, and Docker with zero hassle
  5. Built a foundation that anyone can extend

Takeaway?

Automate the boring stuff, personalize the rest, and keep improving it.

Top comments (0)