Build Awesome Command-Line Applications in Ruby
Control Your Computer, Simplify Your Life
by David Bryant Copeland
Version: P1.0 (March 2012)
Copyright 2012 Pragmatic Programmers, LLC. This book is licensed tothe individual who purchased it. We don't copy-protect itbecause that would limit your ability to use it for yourown purposes. Please don't break this trustyou can use this across all of your devices but please do not share this copywith other members of your team, with friends, or via file sharing services. Thanks.
Dave & Andy.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC.
Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein.
Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://pragprog.com.
Table of Contents
- Common Command-Line
Gems and Libraries
Copyright 2012, The Pragmatic Bookshelf.
What Readers Are Saying About Build Awesome Command-Line Applications in Ruby
Some command-line applications save time and are a joy to use. Others just make you want to tear your hair out. David Copeland has written a guide to writing the kind of command-line apps that will make your users want to hug you. From providing a humane command-line interface, to being self-documenting, to integrating seamlessly with the rest of the command-line universethis book will show you how to take your scripts from adequate to awesome.
Avdi Grimm |
Ruby developer, author, Exceptional Ruby, and blogger, Virtuous Code |
This book proves that text mode is not the just the domain of batch scripts and glue code. Beyond the extensive survey of current Ruby CLI tools, David brings an unmatched focus on user experience and testing. Every full-stack developer should learn how to build the kinds of apps covered in this book.
Wynn Netherland |
CTO, Pure Charity |
I know of no other Ruby book that covers the content in this useful work, especially with its eye toward making Ruby command-line applications better citizens.
Noel Rappin |
Senior engineer at Groupon and author, Rails Test Prescriptions |
This well-written book teaches ideas that are really important: that Ruby is a powerful language for writing command-line tools; that CLI tools, unlike GUI tools, can be combined in an infinite number of ways; that the effort required to automate small recurrent tasks pays off; and that there are time-tested best practices for succeeding with command-line tool development. Not only are the scripts in this volume awesome, so is the book.
Staffan Nteberg |
Author, Pomodoro Technique Illustrated |
I want a few people on my team to have this book now. I especially cant wait to get this in the hands of our software lead, whos a whiz at shell scripts and would be delighted to see how much easier and more reliable option parsing is in Ruby.
Ian Dees |
Ruby developer and coauthor, Using JRuby |
This book teaches you how to write command-line tools your mother would be proud of.
Matt Wynne |
Independent consultant, programmer, coach, and author, The Cucumber Book |
Introduction
Graphical user interfaces (GUIs) are great for a lot of things; they are typically much kinder to newcomers than the stark glow of a cold, blinking cursor. This comes at a price: you can get only so proficient at a GUI before you have to learn its esoteric keyboard shortcuts. Even then, you will hit the limits of productivity and efficiency. GUIs are notoriously hard to script and automate, and when you can, your script tends not to be very portable.
This is all beside the point; we are software developers, and we write programs. What could be more natural than using code to get our work done? Consider the following command sequence:
> cd ~/Projects/cli |
> vi chapter2.md |
While these two commands might strike you as opaque, they are a highly efficient means of editing a file.
For most of my career, the command line meant a UNIX shell, like bash
. The bash
shell provides some basic built-in commands, as well as access to many other standard (and nonstandard) commands that are shipped with any UNIX system. These commands are single-purpose, require no user interaction, and come with easy-to-use (but hard-to-learn) user interfaces. These attributes let you piece them together in a near-infinite number of ways. Automating sophisticated behavior, performing complicated analysis, and parsing a myriad of text files can be done easily and expediently. This was life for me early on in my career. And it was good.
Then, in the mid-1990s, as Java grew in popularity, the idea of stringing together UNIX command-line utilities to get things done came to be seen as archaic. Java programs eschewed simple text-based configuration and file-based input/output (I/O) for complex hierarchies of XML driven by RPC and HTTP I/O. This allowed for very sophisticated systems to be built, and GUI tools sprang up to abstract away the complexity of building and configuring these systems. Even the act of writing and building code got swallowed up by ever more complex integrated development environments (IDEs). The simplicity of the command line was starting to get lost.
The problem is, there are too many tasks that dont fit the model of these tools; its just too darn easy to go out to the shell and get things done. So, while I never bought into the concept that IDEs and sophisticated GUI tools were an advancement of the command line, I made peace with the facts of life and settled into a comfortable pattern: Java was for real code, and the command line (along with Perl and Ruby) was for automation, one-off scripts, and other things that helped me get repetitive things done quickly.
In the mid 2000s, I started to take notice of Ruby, Rails, and the amazing community built up around these tools. To my surprise (and delight), almost everything was command-line driven. Dynamic languages like Ruby dont lend themselves too well to IDEs (some even argue that an IDE makes no sense for such languages), and the burgeoning developer community wasnt on the radar of any top-tier tool makers. The community embraced the command line and created command-line applications for everything. Although Perl had been doing this for years, this was the first time Id noticed such a strong embrace of the command line in the post-Java world.
What was more interesting was the taste and polish put into these command-line apps. Most featured a full-blown help system, often with command-based navigation of features, but still stayed true to the UNIX way of simplicity and interoperability. Take