this post was submitted on 24 Nov 2025
21 points (95.7% liked)

commandline

2132 readers
1 users here now

founded 2 years ago
MODERATORS
 

So I'm sure we've all spent time writing scripts or figuring out CLIs for that one project we're working on, and then kind of go on to forget what we did. Then, when another project comes along later, you wish you had that script again so you could see how you did that thing you did.

Personally, I used to just check random scripts into a repo as a kind of "archive" of all my scripts. But I wanted a better way to organize and use these things.

For years I've been building and collecting these scripts into a CLI that I call Devtools to make it so that each script is a subcommand.

I've had a lot of my friends and coworkers ask me to open-source it so they could use it and see how some things are done in Bash, what tools I use, etc. So...here's that CLI!


But what I'd honestly like is more...

So what are your useful scripts or CLIs you've built? Or what's that script you wrote years ago that you now swear by? Or what's that one application you use daily that just makes your life infinitely easier! I want to grow this collection and feed the addiction!

you are viewing a single comment's thread
view the rest of the comments
[–] stewie410@programming.dev 1 points 1 month ago

Thanks so much for the other stuff you use! I’ve been using bm for years

If you mean from my dotfiles, that's wild. A friend of mine wrote his own implementation in rust, but I've not really used their version, though I'm not sure its on github.

that honestly became kind of cumbersome when I have different configs on different servers, or machines for work vs personal, etc.

While I'm not currently using it, its on my todo list to take a real look at chezmoi for these per-machine differences; especially as I'm always between Linux, Windows & WSL. While chezmoi is outside the scope of this topic, it seems like a pretty solid configuration management option...and probably safer than what I'm doing (ln -s).

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

My "solution" is a collection of templates I'll load in to my editor (nvim, with my ~~lackluster~~ plugin), which contains the basics for most scripts of a certain type. The only time that I'll write something and rely on something that isn't builtin, e.g. a customization, is if:

  • Its a personal/primary machine that I'm working from
  • I require() the item & add testing for it
    • [[ -z "${var}" ]], or command -v usually

For my work, every script is usually as "batteries included" as reasonable, in whatever language I'm required to work with (bash, sh, pwsh or groovy). That said, the only items that appear in nearly every script at work are:

  • Base functions for normal ops: main(), show_help(), etc.
  • Some kind of logging facility with log()
    • colors & "levels" are a pretty recent change
  • Email notifications on failure (just a curl wrapper for Mailgun)

bashly framework

Transpiling bash into bash is probably the weirdest workflow I've ever heard of. While I can see some benefit of a "framework" mentality, if the 'compiled' result is a 30K line script, I'm not sure how useful it is IMO.

For me at least, I view most shell scripts as being simple automation tools, and an exercise in limitation.

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

I did see some of that, even in the transpiled dtools monolith

$(<file)

Just be aware that this reads the full contents into a variable, not an array. I would generally use mapfile/readarray for multiline files. As for the jq example, you should be able to get away with jq '.[]' < file.json, which is also POSIX when that's a concern.

maybe we should work together to update the framework to have better conventions like you’ve mentioned?

I don't think I'm the right person for that job -- I'm both unfamiliar with Ruby and have no desire to interract with it. I'm also pretty opinionated about shell generally, and likely not the right person to come up with a general spec for most people.

Additionally, my initial reaction that bashly seems like a solution in search of a problem, probably isn't healthy for the project.