David Copeland (@davetron5000), author of GLI (Git-like Interface Command Parser) has written a book called Build Awesome Command-Line Applications in Ruby. I’ve been beta-testing the book while it was going through the publishing process, and it is excellent. Of note: it focuses on writing command suites (like the
rails command or
git) and stand-alone command-line applications (like
So like I mentioned up there, I initially grabbed the book around its second or third beta release, figuring that while it was still in the process of becoming a Real Book I sometimes feel like I’m still in the process of becoming a Real Admin so, you know, what the hell, let’s work through it together.
I know a number of developers who only know Ruby in the context of the Rails framework (and maybe related Rake tasks) and this book is an exceptional guide to using Ruby for more than just Rails applications. Command-line tooling has long been an area of interest for me as working in operations means often having to perform a number of repetitive tasks which lend themselves well to being scripted; good admins write good scripts.
To that end, I think there’s a philosophy behind useful scripting and I think that sticking to system tools like Bash (or if you insist, standard bourne shell) whenever possible is always your safest bet. But sometimes it’s just easier or smarter (and sometimes both) to use a language like Ruby or Perl for tasks like string manipulation, data aggregation and analysis, or “glue code”. I think the most important thing this book does is try to instill a general philosophy of how good shell scripts and command line tools are built and maintained.
Beyond its focus on OptionParser (the standard Ruby argv parser library), Build Awesome Command-Line Applications in Ruby also gives a high level but functional overview of some of the popular options (Trollop, David’s own methadone, and main) for parsing options and building help screens for your tools. For those of you who are curious, Slop is also somewhat popular but I understand that reviewing all of the options would have unnecessarily extended the length and scope of the book; you have to draw the line somewhere.
David has written a pretty useful book and I think it’s a must-read for anyone who has to roll their own tools with any regularity. If you work in operations, development, or tooling you owe it to yourself to give it a read if only for the overview of what makes a successful command line tool that people appreciate using and what makes a shitty ad-hoc script with no help screen or sanity checking that your coworkers hate using but no one wants to take the time to refactor.