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.
This should get you a basic working system of scripts.
- Clone this repo to wherever you want my scripts on your system.
build_bin.shto build the bin folder with symlinks to the scripts.
- Add the newly-created bin folder to your $PATH.
- 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.
- Follow the Initial Setup directions first.
- Do the things that bash_custom/install.sh is meant to do.
- Cross your fingers and open a new shell.
- Complain to me if bash_custom/install.sh eats your hamster.
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 build_bin.sh at the top level, here's what to expect if you dig in to the script collection.
|backup||scripts for backing up my computer||
|bash_custom||my .bash* files and such||.bashrc sources the functionality stuff which is stashed away in the "sourced" folder.|
|cpu||scripts for managing CPU throttling||cpu-set-ghz.sh and cpu-frequencies.sh|
|example||scripts that demonstrate various Bash techniques or which are too miscellaneous to go in other folders||I think that tuple_funcs.sh is a neat demonstration of simulating arrays in Bash.|
|filesystem||scripts for keeping the filesystem running smoothly||
|found||scripts that I found online and have no interest in changing|
|fun||scripts related to computer games and such|
|keyboard||keyboard controlling stuff||layout.sh turns Scroll Lock into "Dvorak Lock", sets Caps Lock as an extra backspace, and sets Menu as Compose.|
|net||networking scripts||download-site.sh recursively downloads a site to a preset location|
|proc||manage processes freezing|
|screen||override screen locking and manage Redshift||
|shortcut||shortcut commands that may be useful for scripts and stuff|
|sourced||scripts that are sourced by my .bashrc for setting up my custom Bash environment||prompt 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.|
|speech||front-end to spd-say command for text-to-speech||say.sh pretty much does the same as "say" on OS X.|
|system||general system-y things||
|volume||controls volume from the command line||volume-* 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:
- A script calls a command or other script that cannot be found.
- A script's dependency changes in a way that breaks how it's called.
- 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:
- Use something like
if ! which cmd1 cmd2; then exit 1; fito do a quick sanity check at the beginning of each script that uses custom commands.
- Localize generally-useful dependency scripts into the
libfolder 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.
- Refactor common functionality into new scripts with locations as described in #2.
Finally, I'll try to avoid these issues in the future.
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
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.