invoice VS sysbox

> Unsurprisingly I disagree with the post's description of awk being an "advanced command".

I think it can be pretty advanced, for me awk is one of those tools where I still feel like I need to write a paragraph of comments to explain 1 line of code.

For example: https://github.com/nickjj/invoice/blob/master/invoice#L11-L3...

Keep in mind I don't really "know" awk. I cobbled that together from a few examples.

NOTE: I wrote that script 3.5 years ago and I know there's questionable patterns in other areas of the script that's not highlighted like using a bunch of separate echo calls instead of a heredoc.

A whole bunch of little things, mainly command line tools.

Most of them are open source and also have extensive documentation and a screencast video going over them.

In no specific order:

- https://github.com/nickjj/notes

- https://github.com/nickjj/invoice

- https://github.com/nickjj/wait-until

And a few recent little scripts to solve specific things:

- https://nickjanetakis.com/blog/using-ffmpeg-to-get-an-mp3s-d...

- https://nickjanetakis.com/blog/a-shell-script-to-keep-a-bunc...

- https://nickjanetakis.com/blog/bash-aliases-to-prepare-recor...

Yes, I first learned this and the name "splay" from CFengine, back in the day.

I put together a small busybox-like collection of sysadmin tools, and one of the subcommands is "splay" to sleep for a random amount of time. It's one of those things that is useful surprisingly often, even outside cron.

https://github.com/skx/sysbox

I remember in 1999 there was a project to reimplement a bunch of these tools in perl:

https://perlpowertools.com/

I even contributed a little, back then. I guess writing basic versions of "ls", for example, is trivial. But there's a lot of work getting all the tools done, with all the flags implemented and behaving as expected.

I guess there are tools like busybox, toybox, and similar, which also implement a lot of "stuff" to varying degrees of completion. From my side the biggest takeaway from those projects is the sheer convenience of deploying a single binary and installing symlinks to change functionality.

I replicated something similar with my sysbox project, collecting tools together in one golang binary with various subcommands:

https://github.com/skx/sysbox

I use at least one of those tools on a daily basis, though I suspect they're not so universally useful.

If you've got perl installed you'll might have a "GET" binary present, mine is /usr/bin/GET, which comes with the WWW-module.

Although this is written in portable perl, rather than being compiled, so the static vs. dynamic choice doesn't really mean much it is a simple alternative.

Otherwise I built a simple busybox-inspired collection of tools, written in golang, which includes a simple HTTP client too:

https://github.com/skx/sysbox

Those are just a couple of examples, I'm certain there are multiple other choices out there. But I guess curl is ubiquitous enough that most people just use it directly, and add it when missing!

That's pretty cool.

I wrote something similar in my static collection of sysadmin tools - https://github.com/skx/sysbox - In my simple pre-processor I only allow two special things:

#include "file/goes/here"

I bundled together a small collection of sysadmin/scripting-tools here:

https://github.com/skx/sysbox

Those are probably amongst the things that I use most often which are non-standard.

I used to have very full ~/bin, and ~/$(hostname), directories. In the end I pared them back and started bundling things together in one binary.

The end result is very similar to this approach, I run "sysbox blah", or "sysbox help", and use integrated subcommands.

Very helpful and makes deployment easy by having only a single binary:

https://github.com/skx/sysbox

Not bash/shell, but similar and useful idea to experiment with.

I support that in my sysbox utility-box, via the subcommands processor, and it is very helpful.