Skip to content
A collection of personal Bash scripts I've developed over the years. They may be useful to others.
Shell Python
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


This repository contains most of the personal Bash scripts I've developed over the years. They cover a wide variety of tasks and reflect the process of me learning more and more Bash. Please see the Contents section below to see which scripts may interest you.


I'm using the Unlicense for making my scripts public domain, so you may freely use most of these scripts however you want to. My scripts are free as in freedom, free as in beer, and free as in not liable. Use at your own discretion.

For scripts that specify another license, their license is as stated. See the LICENSE file and check each script's source for more information.


For the most part, you can get away with just copying a script to wherever and running it. However, some scripts depend on others, some depend on a system configured similar to mine, and others need to be integrated with Bash. If my scripts aren't playing nice with your system or installation is too tricky, then please open a GitHub ticket or email me. I want my scripts to be properly general, as long as there's demand.

Anyway, here's how my setup is installed. Similar steps should work for you. Complain to me if it doesn't work.

Initial Setup

This should get you a basic working system of scripts.

  1. Clone this repo to wherever you want my scripts on your system.
  2. Run to build the bin folder with symlinks to the scripts.
  3. Add the newly-created bin folder to your $PATH.
  4. Complain to me when a script is hard-coded to my system's setup.

Bash Environment Setup

This should get you a Bash shell environment similar to mine. As of this writing, such integration or similar is required for shell-environment-changing things like the "cmcd" command to work correctly.

  1. Follow the Initial Setup directions first.
  2. Do the things that bash_custom/ is meant to do.
  3. Cross your fingers and open a new shell.
  4. Complain to me if bash_custom/ eats your hamster.

System-specific Setup

There's too much integration to describe this. Instead, I need to refactor the scripts to use config files for system-specific stuff instead of hard-coding it. Please help me by complaining about scripts you want to use being hard-coded to my system.


Beyond this readme, the license file, and at the top level, here's what to expect if you dig in to the script collection.

FolderContentsMain scripts
backupscripts for backing up my computer
  • - full system backups via btrfs snapshots
  • - use adb to pull user data from Android system folders
bash_custommy .bash* files and such.bashrc sources the functionality stuff which is stashed away in the "sourced" folder.
cpuscripts for managing CPU and
examplescripts that demonstrate various Bash techniques or which are too miscellaneous to go in other folders I think that is a neat demonstration of simulating arrays in Bash.
filesystemscripts for keeping the filesystem running smoothly
  • - search custom Bash history folder
  • - much easier than calling cp with a zillion args and really long paths
  • - scrub multiple btrfs volumes at once
foundscripts that I found online and have no interest in changing
funscripts related to computer games and such
keyboardkeyboard controlling turns Scroll Lock into "Dvorak Lock", sets Caps Lock as an extra backspace, and sets Menu as Compose.
netnetworking recursively downloads a site to a preset location
procmanage processes freezing
screenoverride screen locking and manage Redshift
  • - keep a KDE session from entering sleep/standby mode
  • - front-end for configuring Redshift more easily
shortcutshortcut commands that may be useful for scripts and stuff
sourcedscripts that are sourced by my .bashrc for setting up my custom Bash environmentprompt is probably the most interesting script here. It sets my $PROMPT_COMMAND for using a custom history folder and it sets $PS1 to provide colored time instead of user@host.
speechfront-end to spd-say command for pretty much does the same as "say" on OS X.
systemgeneral system-y things
  • automates certain mount points needed for system stuff to work in the chroot
  • acts like the Ubuntu update-grub command
  • is a rewritten version of Chakra Linux's mirror-check script
volumecontrols volume from the command linevolume-* scripts increase, decrease, and (un) mute the volume

Dependencies - in progress

Right now the state of dependencies in my scripts is undefined. Here's the situation and how I plan to fix it.

Most scripts are useless without some other command that is not part of the shell. Bad things happen if the command is not found. Here are my use cases:

  1. A script calls a command or other script that cannot be found.
  2. A script's dependency changes in a way that breaks how it's called.
  3. Some scripts have functionality in common and it's annoying to handle the duplicate code.

Here's what I plan to do about these cases:

  1. Use something like if ! which cmd1 cmd2; then exit 1; fi to do a quick sanity check at the beginning of each script that uses custom commands.
  2. Localize generally-useful dependency scripts into the lib folder and other dependency scripts into the folders that contain the scripts they're used in. This makes it easier to avoid breaking dependencies, but doesn't solve the problem. Suggestions are welcome and encouraged.
  3. Refactor common functionality into new scripts with locations as described in #2.

Finally, I'll try to avoid these issues in the future.

Future Plans

My computer use and understanding evolve constantly. So the main goals for these scripts are to make them general enough for future changes and simple enough for present use.

One key criterion for both generality and simplicity is that other people can easily setup and use my scripts if they want to. So if a script doesn't work easily for you, or you have a better idea, please send me your feedback and I'll try to make it better.

In absence of feedback, I think the biggest long-term usability issue is that many scripts hard-code my system's specifics instead of using config files. Hard-coded stuff should be extracted into config files under $HOME/.config/refola.

The biggest functionality addition planned is to streamline my "one-home-per-distro with some shared config" setup (useful workaround for cross-distro incompatibilities, with a cleaner /home/$USER as a nice side-effect) and integrate that into these scripts. Eventually, I might even have a decent script for automagically configuring per-distro home folders and account stuff for multiple users on multiple distros.

Everything else is just the regular ad-hoc want-build-test-refactor loop.

You can’t perform that action at this time.