arctic-hen7
/
bonnie
Super-fast command aliases with arguments.
Bonnie
Bonnie is a command aliasing tool. If you have a super-long command that you have to run all the time, Bonnie is for you! Just define the command in bonnie.toml
at the root of your project, and you're good to go!
[scripts]
short = "really long command..."
For example, if you're running docker-compose
a lot, and you have a custom environment variables file, it's annoying to type out docker-compose --env-file .my.env ...
every time you want to do something! Bonnie can shorten this easily!
[scripts]
dc = "docker-compose --env-file .my.env %%"
The double percent sign (%%
) at the end tells Bonnie to append any arguments you provide to the end of the command.
You can even insert custom arguments into custom places in a custom order!
[scripts]
greet.cmd = "echo \"Greetings %lastname. I see your
…Over the last two weeks, I've been moving away from NodeJS and the JavaScript ecosystem to a great extent, mostly because I think the JavaScript world has blown itself out of proportion. To make a basic, performant, modern app, you now need to spend at least a day on proper boilerplate. The number of frameworks has grown exponentially, and I think the ecosystem is just flooded.
So, I decided to try out Elm, a functional programming language with no runtime errors (yes, only compile-time errors). It's fantastic! However, Elm is not designed for the backend, so I decided to finally learn Rust, something I've been meaning to do for about a year now.
Having adopted these two new languages, I found myself wanting a good system to shorten commands for me - like NPM or Yarn scripts. Make was the most obvious option, but it feels somewhat overkill for essentially an aliasing system. Makefiles also have their own syntax, which, although miniscule, was not something I had any desire to delve into. Instead, I decided my first Rust project would be a replacement for NPM and Yarn scripts - Bonnie!
Bonnie is a super-fast command aliasing tool designed to replace NPM or Yarn scripts entirely. You can define simple commands like so:
[scripts]
greet = "echo Hello World"
And then run them like this:
bonnie greet
You can mimic the default behavior of NPM and Yarn scripts, to append any given arguments to the end of the command, by adding the double percent sign (%%
) to the end of the command:
[scripts]
greet = "echo Hello %%"
And you can add arguments to the end easily when you run it:
bonnie greet Donald Knuth in math-land
You can even add specific arguments for aliases to take:
[scripts]
greet.cmd = "echo Hello %firstname %lastname"
greet.args = [
"firstname",
"lastname"
]
And those can be run like so:
bonnie greet Donald Knuth
Bonnie will gracefully tell you when you've done something wrong, like provided too few arguments, or used invalid syntax in your config file. By default, that config is stored at bonnie.toml
, but you can specify an alternative path by setting the BONNIE_CONF
environment variable.
This is my first ever CLI, and it's also the first time I've used GitHub Actions to automate building my code on different OSes! Bonnie has binaries available for Linux, MacOS, and Windows on the releases page.
I think Bonnie has been a great opportunity for me to dive into a complex language like Rust head-first, because no matter how long you spend poring over the Rust Book (about 7 hours in my case), you can never learn programming without actually building something. In the particular case of Rust, you can never get your head around lifetimes without actually building something!
I'm using Bonnie daily now, and so far it's working really well! I'm not aware of any alternatives to NPM and Yarn scripts that are as simple as Bonnie, and I hope this will help some people!
Top comments (2)
Hey arctiv_hen7,
Thank you for making this cli!
I had this problem too and I'm glad to have found your cli :)
However, I think you can improve the deployment a bit (at least for macos).
Please add somewhere to the readme, that one has to make the download from your release page executable on their system, otherwise executing it will not work.
Also the executable must be added to their path.
I know, most developers will know this, but if it's in the readme, it'll be easier :)
Your executable is not fully signed & trusted by apple and therefore the user has to jump through some warning screens at first execution.
You can look at my repo of macos-file-summoner here, which is a go based tool and is fully signed and runs on macos without any security warnings:
github.com/bjesuiter/macos-file-su...
Ok, I admit, the automatic apple verification process over github actions is quite complicated, i wrestled with it for 3 or 4 days straight. :D But at least you could use that as a baseline and tweak it afterwards. ^^
If you want, I may look into the specification on how to provide a homebrew package and make a PR for you.
I hope, these suggestions do not sound aggressive. I'm only a happy developer myself and want to contribute to cool things I find on the internet :)
Have a nice day!
Hey thanks so much! PRs are always welcome, and that'd be great! I don't have a Mac, so your insight is greatly appreciated! That's a very fair point on the README, and I'll make that clearer!