I distinctly remember, as a freshman in college, asking a local guru how to rename a file in Unix. “It’s mv,” he said “for ‘move’.” To me, he was a Unix god, and here I was not even knowing mv. Hey, we all have to start somewhere.
No matter where you’re starting, Mark Bates’s Conquering the Command Line is for you. Mark is an expert developer, lucid writer, and acclaimed speaker, and I can’t think of a better guide to the ins and outs of the Unix command line from the perspective of a working developer rather than a Unix sysadmin. Mark’s approach is not to give you an exhaustive and overwhelming catalog of each command and everything it can do, but rather to carefully select the most important commands and the most useful options. In other words, this is a curated introduction to the Unix command line.
Conquering the Command Line starts with the essential basics—things like pwd, ls, and cd—and then takes you on a tour of the more exotic animals in the Unix zoo. The result is that you’ll quickly move past mv to master commands like curl, grep, find, and ack—not to mention ps, tar, and sed. Because of the ubiquity of Unix, the knowledge you gain will serve you well whether you use OS X, Linux, or *BSD. (And if you’re stuck running Windows—well, you can always install a Linux virtual machine.)
I certainly don’t consider myself a Unix god, or indeed any other kind of OS deity. For all I know, neither did that local guru. But we can all aspire at least to demigod status, and Conquering the Command Line will help get you there. Please remember, though, to use your new-found Unix powers for good, not for evil—with great sudo comes great responsibility.
This book is for new developers, experienced developers, and everyone in between who wants to master Unix and Linux commands. This book was designed to showcase some of the most useful commands that a developer can know to help them in their daily tasks.
This book is not an exhaustive manual for each of these commands; in fact, it is just the opposite. Instead of just collecting up MAN pages, this book pulls out the most useful flags, options, and arguments for each of the commands in the book.
By learning and understanding the subset of flags, options, and arguments for each command, you’ll be able to more efficiently use each one in your daily development workflow - while understanding where to look to find the more esoteric options you’ll only need occasionally.
For most of the examples in this book we will use the Rails source code as a way to demonstrate a lot of the commands we will look at.
The source code for Rails can easily be downloaded from GitHub using Git.
$ git clone git@github.com:rails/rails.git
$ cd rails
If you don’t have Git installed, which you should, you can download the zip of the Rails source code at https://github.com/rails/rails/archive/master.zip.
Because Rails is an ever changing code base, your results may vary from those in the book as the source code changes.
Books are not written in a vacuum, and this book was no exception. It is easy to assume that since there is only one name on the cover of this book, that there is only person responsible for bringing it all to fruition - when in fact, this couldn’t be any further from the truth.
I have a lot of people to thank for helping to get this book in your hands, yourself included. If I didn’t think people such as yourself would want to read this book, I wouldn’t have written it, so thank you so much.
I would like to thank Michael Hartl, and the entire team at Softcover, for developing a great set of publishing tools meant for people such as myself, the technical writer. I have written two books prior to this one, and I have to say that I have never used tools as good as these for writing a book before. The platform just got out of my way and let me focus on writing, and not on constantly trying to figure out how to format things, why my PDF wasn’t generating correctly, etc…
Next I would like to thank my fantastic team of technical reviewers. The tech reviewers on this book were Pat Shaughnessy, Michael Denomy, Pete Brown, Johnny Boursiqout, and Dan Pickett. They tirelessly waded through each chapter as I wrote it, and they submitted some amazing pull requests to improve both the quality of the content as well as the prose itself. Their questions, suggestions, subtractions, and additions, made this book significantly better than I could have ever written on my own. I’m eternally grateful to each of them for donating their time, and mindshare, so freely. If you see them at a conference, user group, or in the street, give them a big hug and say thanks.
Lastly, the most important thank you I can give is to my family. I have to be the luckiest man on the planet to have such an amazing, and understanding wife. She supports me, she pushes me, she believes in me, and most importantly, she makes my life better. I can’t express how much I owe to her for all she has done and given to me, including our two beautiful boys. Thank you Rachel, as always, this book is dedicated to you.
Well, enough gushing - I just hope you enjoy this book, and that it helps you as much as I hope it will. Enjoy.
The story of how this book came to be started in April of 2013 at RailsConf in Portland, Oregon. At RailsConf I was hanging out with Michael Hartl, author of the Rails Tutorial. Michael and I had known each other for a few years through conferences, as well as both being authors for Addison-Wesley.
Over dinner one night, Michael started telling me that he was thinking of building a self-publishing platform for technical writers, and was pumping me for information about what kind of a platform I would like to write books on. I left RailsConf not thinking too much more about Michael’s idea, as I had vowed to never write another book.
Fast forward a couple of months to June, 2013. I was in Los Angeles for a friend’s wedding. I drove up to Pasadena one night to meet Michael for dinner, and the strongest Margaritas I have ever had. During dinner Michael, as he’s prone to do, pulled out his laptop and started to demonstrate his publishing platform to me. I have to admit, I thought it looked really nice. He proceeded to spend the rest of the night trying to convince me that I should be a guinea pig for him and write another book, this time using his platform.
After I left Los Angeles, I headed back to Boston, packed quickly, and boarded a plane to Stockholm with my wife and kids, to spend the entire month of July working for a client I had there.
While at my client’s office, I had several conversations with some developers who had no idea how to do even those most basic of commands on their systems. They were petrified of the command line. They could do simple stuff like change a directory, move a file, etc., but they couldn’t un-tar a file, or find runaway processes. I found this incredibly frustrating as most developers spend their whole day in a terminal window, and here was a whole group of people that weren’t getting the most they could from the powerful tools at their disposal.
This lack of command line knowledge bothered me for several days. I was obsessed with how these developers could get this far, without this knowledge. I started to ask myself questions such as how had I acquired these skills? The answer was I was lucky enough to have great mentors over the years who passed on tiny snippets of commands that were incredibly useful. I also thought about what would keep people from learning how to use these commands.
I came to the conclusion that one of the biggest obstacles for developers, particularly new developers, is the system that is supposed to help developers understand these commands: man pages. Man pages (man being short for manual) are supposed to be manuals that explain these commands in great detail - including every last option and flag. They are daunting, overwhelming, and confusing beasts that bewilder even the most “senior” developer.
This realization came to me while I was standing in line to buy tickets to the Vasa Museet. I realized what was needed was a book that picked out the most useful commands a developer needs every day. On top of that, the most useful flags and options need to be explained in simple terms, with clear examples, that can be of immediate use for a working developer.
As I stood in line, I shot off an email to Michael explaining my idea and to get his thoughts on the subject matter and whether or not he thought it would be a good fit for his Softcover platform. It was seconds before he responded with an overwhelming “YES!”, and that was how I became the first author to publish on Softcover.
I loved writing this book. It wasn’t always easy, no book ever is, but it was incredibly educational. I found new tools, new flags, and new options that have radically changed the way I work everyday. I have found myself referring to this book, while I was writing it. I have incorporated all of these tools into my daily work flow, and I hope you do too.
So with that said, let’s dive right in.
Mark Bates January, 2014