<commit_before># bashctl
bashctl is a small set of functions (the full list is available in the main help file) for writing, organising, running and sourcing bash/sh scripts and definitions (functions, aliases, etc.).

## A little history
###### (skip this bit if you don't care and just want to use it)
To be honest, I didn't even look for software or scripts for script/definition development and management before I wrote this. This was partially because at the time I didn't do much customization and because this project started out a lot smaller than it is now. [The very original version](https://github.com/musicmrman99/bashctl/blob/master/misc-info/src.sh.orig) was put straight into my `.bashrc`. Then it grew a bit and I put it in a separate script I sourced in my `.bashrc` called `ualias.sh` (for 'User-defined Aliases', ie. not the predefined ones in Ubuntu's default `.bashrc`), as it was originally only for organizing aliases, before I got onto writing more complex scripts and functions. I thought it would be quicker to write something myself just to source the aliases I used than to search for something that did the same, and originally it probably was. But then I started to think 'oh, I need it to do *this* as well', 'ooh, and *this*', 'and *that*', ... Each time I wanted another feature, I kept thinking "well, it's just one more feature, it can't be that hard ...". And each individual feature wasn't too hard (sort of), only, they kept piling up.

Over time `ualias` changed to encompass functions and the name was changed to `src` (in fact, I kept that name for that part of `bashctl`). Then I added the ability to execute scripts as well as source them and the name changed to `bash-exec`. But `bash-exec` sounds a bit too similar to the `exec` system call, which doesn't work in the same way that `bash-exec` actually did. So, I changed its name one last time to `bashctl`, without modifying any code (the name is derived from `systemctl`, from systemd).

Then, when I finally plucked up the courage to share my code on GitHub, I realised I had an irritation: `.git`. That folder and the other files that GitHub adds to a project, like `README.md` and `LICENSE`, looked messy in my Bash Library once I'd pulled the repo in, not to mention the fact that I could *theoretically* execute these files with `bashctl`. So, back to the editor for me ;) I invented a system whereby I could:
1. hold the files for the library in subdirectories of a separate directory (`$BASH_LIB_COMPONENT_ROOT`, for which I often use the folder `~/Bash Library - Components`), then
2. symlink to these files in the main library (`$BASH_LIB_ROOT`, usually `~/Bash Library`), excluding any files I don't want to show through the use of a blacklist file (`blacklist.txt`).

As for the present, this little project may well gather dust and end up only being used by me, but there's no reason not to share ... just in case.

## Why use it?
###### (you should probably still read this, though)
Because it's useful. It's not **awesome**, it doesn't reimagine how you use the shell and it's not the perfect tool for *every* job. It's just useful for some.

Reasons why it's useful:
- It's simple<commit_msg>add whitelist feature to doc<commit_after># bashctl
bashctl is a small set of functions (the full list is available in the main help file) for writing, organising, running and sourcing bash/sh scripts and definitions (functions, aliases, etc.).

## A little history
###### (skip this bit if you don't care and just want to use it)
To be honest, I didn't even look for software or scripts for script/definition development and management before I wrote this. This was partially because at the time I didn't do much customization and because this project started out a lot smaller than it is now. [The very original version](https://github.com/musicmrman99/bashctl/blob/master/misc-info/src.sh.orig) was put straight into my `.bashrc`. Then it grew a bit and I put it in a separate script I sourced in my `.bashrc` called `ualias.sh` (for 'User-defined Aliases', ie. not the predefined ones in Ubuntu's default `.bashrc`), as it was originally only for organizing aliases, before I got onto writing more complex scripts and functions. I thought it would be quicker to write something myself just to source the aliases I used than to search for something that did the same, and originally it probably was. But then I started to think 'oh, I need it to do *this* as well', 'ooh, and *this*', 'and *that*', ... Each time I wanted another feature, I kept thinking "well, it's just one more feature, it can't be that hard ...". And each individual feature wasn't too hard (sort of), only, they kept piling up.

Over time `ualias` changed to encompass functions and the name was changed to `src` (in fact, I kept that name for that part of `bashctl`). Then I added the ability to execute scripts as well as source them and the name changed to `bash-exec`. But `bash-exec` sounds a bit too similar to the `exec` system call, which doesn't work in the same way that `bash-exec` actually did. So, I changed its name one last time to `bashctl`, without modifying any code (the name is derived from `systemctl`, from systemd).

Then, when I finally plucked up the courage to share my code on GitHub, I realised I had an irritation: `.git`. That folder and the other files that GitHub adds to a project, like `README.md` and `LICENSE`, looked messy in my Bash Library once I'd pulled the repo in, not to mention the fact that I could *theoretically* execute these files with `bashctl`. So, back to the editor for me ;) I invented a system whereby I could:
1. hold the files for the library in subdirectories of a separate directory (`$BASH_LIB_COMPONENT_ROOT`, for which I often use the folder `~/Bash Library - Components`), then
2. symlink to these files in the main library (`$BASH_LIB_ROOT`, usually `~/Bash Library`), excluding any files I don't want to show through the use of a blacklist file (`blacklist.txt`) and/or whitelist file (`whitelist.txt`).

As for the present, this little project may well gather dust and end up only being used by me, but there's no reason not to share ... just in case.

## Why use it?
###### (you should probably still read this, though)
Because it's useful. It's not **awesome**, it doesn't reimagine how you use the shell and it's not the perfect tool for *every* job. It's just useful for some.

Reasons why it's useful:
- It's simple
{'fraction_non_alphanumeric': 0.07574586489411038, 'fraction_numerical': 0.001236667181944659, 'mean_word_length': 4.281632653061225, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4453498', 'n_tokens_mistral': 1780, 'n_tokens_neox': 1662, 'n_words': 1069}