Anyone who knows me, knows that I am most comfortable and at home on the unix/linux command line.
I am also a tool builder and love automating toil away. While I have formed my own set of guidelines for creating tools over decades of practice, I have never actually written many of them down.
No need to now!
I found this over the weekend: Command Line Interface Guidelines
If you are a command line tool builder, you want to read this!!
I came across that website via CLI Guidelines Aim to Help You Write Better CLI Programs which has a good summary of what you will find there and also worth the read for a bit of history.
If I can find any fault with Command Line Interface Guidelines at all, it might be the lack of references to command line editing and recalling of history which I use extensively.
There are many programs that can be built with the readline library. The ones I use the most are bash, mysql, R, bc, gnuplot. There are others like python, tclsh, wish… It comes in handy to recall complex command lines when you might only need to change a few parameters and re-execute. You can also create your own command line programs with history editing of course, even with bash which I did here: Interactive Bash Scripts
What I find amazing is that many of the sysadmins and SRE’s I meet, while spending so much time on the command line, don’t know how to set themselves up with what is usually their preferred editor. More often than not they say they use VI rather than emacs and yet they are unaware that a simple config file in their home directory will leverage this hard-won knowledge with all of these command line programs. I’ve previously written about that here: vi or emacs? Really?!?
I don’t know of a comprehensive list of programs that use the readline library, but I can point you where you need to go to start building it into your command line programs. Start here: The GNU Readline Library and there is more information here: Things You Didn’t Know About GNU Readline