In this post, I argue that in programming, it is no longer about Bash or any other language. It is about habits of mind. The shell merely provides the vocabulary through which we learn them.

Most programming books begin with variables, loops, and functions. A textsmith, however, encounters programming from the opposite direction: composition. Before writing a single if statement, they are already composing grep, sort, awk, sed, pandoc, and dozens of other tools into something larger. By the time they sit down to learn a programming language, they have already been programming—they simply didn’t call it that.

Before long, every Linux user accumulates little command snippets. A clever find pipeline copied from a forum. A five-line shell script that renames photographs. An awk one-liner that extracts exactly the report you need. The question is not whether you will collect these solutions. The question is whether you will lose them.

This post continues the discussion on shell scripting. In a sense, a shell script is simply text that instructs other text-processing tools how to cooperate.

In a previous post, I discussed handling personal frustration through building my own utility, and learning programming in the process. The question now is: at what point should a group of commands, ofen represented as one-liners, be turned into a script?