commandline

Thanks so much for the other stuff you use! I've been using bm for years, but I haven't used mkcd, so I'm definitely going to add that.

I'm going to give your library, config, and AoC a good look because that's exactly what I was hoping for in this conversation! :)

In general: The only time I add it to my ~/.bashrc is when it's either an alias for something simple, or a very simple function. Otherwise, anything that requires more legwork or is bigger than a few lines, I put in dtools. I used to put it all in my ~/.bashrc but that honestly became kind of cumbersome when I have different configs on different servers, or machines for work vs personal, etc. And sometimes the exports would differ making functions work differently and I didn't want to just have to copy that section of my ~/.bashrc as well every time something updated, hence why I created the dtools repo!

To respond to your other comments, I'm going to do my best to respond in the order they show up:

printf vs echo through bold() vs $'\e[1m'

The dtools script is actually compiled, not written by me. So in the vast majority of the project, my code is all in the src directory, not in the dtools script. In fact, my repo without compilation consists of only 3k lines. The compiled code in the script then makes up the completions, coloring, some error handling, validations, filters, help messages, constraints (like conflicting flags), etc.

So many of the echos you see are from the bashly framework, not my code. I often use heredocs for longer or multiline strings (being SUPER careful when using <<-EOF to make sure my damn editor is using TABs...that's such a nightmare otherwise 😂 ).

If you look through my code in particular, you'll see I use many of these bash-isms you've mentioned!

So the One vs Many comment is exactly how the repo works! Each subcommand is its own directory and file. So, for example: All dtools aws commands are in the src/commands/aws directory. And any further subcommands like dtools aws secretsmanager are in another subdirectory where each command has its own individual script!

Bashisms

I'm familiar with many of the bashisms you mentioned except the var="$(< file)" one, that's awesome! I've been trying to migrate away from using cat to just output file contents and use more direct, purpose methods that are often built into tools (like jq '.[]' file.json instead of cat file.json | jq '.[]'). However, I'll say that when I'm trying to read each line into an iterable array, I often use readarray too.

grep | awk | sed

I've been trying for years to get more people to look into awk because it's amazing! It's so undervalued! sed takes some getting used to with the pattern and hold space but it's worth the initial suffering 😛

Shellcheck

I've got my Helix editor set up with Shellcheck! It's awesome! You'll notice if you look at my code directly that there's a number of places I have to do # shellcheck disable=SC2154 (a variable is referencing an undefined value). This is because the framework creates and passes those variables to my scripts for me.

A Loose Offer

You seem a lot like me in that you do a LOT of bash scripting! So I'll admit to the fact that I've looked at the compiled code and noted that the most important code is mine, and while there's a lot of things going on in the compiled script, I agree with most of it. But I've also been a bit concerned about how often it's spawning subshells when it doesn't have to.

I think I can fix some of them with associative arrays if I add a minimum bash version requirement in my config, but I've honestly never tried. I'll check that out now!

Since you make a solid point about a lot of this that should maybe be updated in the Bashly framework, maybe we should work together to update the framework to have better conventions like you've mentioned?