A book about the command line for humans.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

167 lines
8.2 KiB

8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
  1. 5. general purpose programmering
  2. ================================
  3. I didn't set out to write a book about programming, _as such_, but because
  4. programming and the command line are so inextricably linked, this text
  5. draws near the subject almost of its own accord.
  6. If you're not terribly interested in programming, this chapter can easily
  7. enough be skipped. It's more in the way of philosophical rambling than
  8. concrete instruction, and will be of most use to those with an existing
  9. background in writing code.
  10. -> ✢ <-
  11. If you've used computers for more than a few years, you're probably viscerally
  12. aware that most software is fragile and most systems decay. In the time since
  13. I took my first tentative steps into the little world of a computer (a friend's
  14. dad's unidentifiable gaming machine, my own father's blue monochrome Zenith
  15. laptop, the Apple II) the churn has been overwhelming. By now I've learned my
  16. way around vastly more software --- operating systems, programming languages and
  17. development environments, games, editors, chat clients, mail systems --- than I
  18. presently could use if I wanted to. Most of it has gone the way of some
  19. ancient civilization, surviving (if at all) only in faint, half-understood
  20. cultural echoes and occasional museum-piece displays. Every user of technology
  21. becomes, in time, a refugee from an irretrievably recent past.
  22. And yet, despite all this, the shell endures. Most of the ideas in this book
  23. are older than I am. Most of them could have been applied in 1994 or
  24. thereabouts, when I first logged on to multiuser systems running AT&T Unix.
  25. Since the early 1990s, systems built on a fundamental substrate of Unix-like
  26. behavior and abstractions have proliferated wildly, becoming foundational at
  27. once to the modern web, the ecosystem of free and open software, and the
  28. technological dominance ca. 2014 of companies like Apple, Google, and Facebook.
  29. Why is this, exactly?
  30. -> ✣ <-
  31. As I've said (and hopefully shown), the commands you write in your shell
  32. are essentially little programs. Like other programs, they can be stored
  33. for later use and recombined with other commands, creating new uses for
  34. your ideas.
  35. It would be hard to say that there's any _one_ reason command line environments
  36. remain so vital after decades of evolution and hard-won refinement in computer
  37. interfaces, but it seems like this combinatory nature is somewhere near the
  38. heart of it. The command line often lacks the polish of other interfaces we
  39. depend on, but in exchange it offers a richness and freedom of expression
  40. rarely seen elsewhere, and invites its users to build upon its basic
  41. facilities.
  42. What is it that makes last chapter's `addprop` preferable to the more specific
  43. `markpoem`? Let's look at an alternative implementation of `markpoem`:
  44. <!-- exec -->
  45. $ cat simple_markpoem
  46. #!/bin/bash
  47. addprop $1 meta-ok-poem
  48. <!-- end -->
  49. Is this script trivial? Absolutely. It's so trivial that it barely seems to
  50. exist, because I already wrote `addprop` to do all the heavy lifting and play
  51. well with others, freeing us to imagine new uses for its central idea without
  52. worrying about the implementation details.
  53. Unlike `markpoem`, `addprop` doesn't know anything about poetry. All it knows
  54. about, in fact, is putting a file (or three) in a particular place. And this
  55. is in keeping with a basic insight of Unix: Pieces of software that do one
  56. very simple thing generalize well. Good command line tools are like a hex
  57. wrench, a hammer, a utility knife: They embody knowledge of turning, of
  58. striking, of cutting --- and with this kind of knowledge at hand, the user can
  59. change the world even though no individual tool is made with complete knowledge
  60. of the world as a whole. There's a lot of power in the accumulation of small
  61. competencies.
  62. Of course, if your code is only good at one thing, to be of any use, it has to
  63. talk to code that's good at other things. There's another basic insight in the
  64. Unix tradition: Tools should be composable. All those little programs have to
  65. share some assumptions, have to speak some kind of trade language, in order to
  66. combine usefully. Which is how we've arrived at standard IO, pipelines,
  67. filesystems, and text as as a lowest-common-denominator medium of exchange. If
  68. you think about most of these things, they have some very rough edges, but they
  69. give otherwise simple tools ways to communicate without becoming
  70. super-complicated along the way.
  71. -> ✤ <-
  72. What is the command line?
  73. The command line is an environment of tool use.
  74. So are kitchens, workshops, libraries, and programming languages.
  75. -> ✥ <-
  76. Here's a confession: I don't like writing shell scripts very much, and I
  77. can't blame anyone else for feeling the same way.
  78. That doesn't mean you shouldn't _know_ about them, or that you shouldn't
  79. _write_ them. I write little ones all the time, and the ability to puzzle
  80. through other people's scripts comes in handy. Oftentimes, the best, most
  81. tasteful way to automate something is to build a script out of the commonly
  82. available commands. The standard tools are already there on millions of
  83. machines. Many of them have been pretty well understood for a generation, and
  84. most will probably be around for a generation or three to come. They do neat
  85. stuff. Scripts let you build on ideas you've already worked out, and give
  86. repeatable operations a memorable, user-friendly name. They encourage reuse of
  87. existing programs, and help express your ideas to people who'll come after you.
  88. One of the reliable markers of powerful software is that it can be scripted: It
  89. extends to its users some of the same power that its authors used in creating
  90. it. Scriptable software is to some extent _living_ software. It's a book that
  91. you, the reader, get to help write.
  92. In all these ways, shell scripts are wonderful, a little bit magical, and
  93. quietly indispensable to the machinery of modern civilization.
  94. Unfortunately, in all the ways that a shell like Bash is weird, finicky, and
  95. covered in 40 years of incidental cruft, long-form Bash scripts are even worse.
  96. Bash is a useful glue language, particularly if you're already comfortable
  97. wiring commands together. Syntactic and conceptual innovations like pipes are
  98. beautiful and necessary. What Bash is _not_, despite its power, is a very good
  99. general purpose programming language. It's just not especially good at things
  100. like math, or complex data structures, or not looking like a punctuation-heavy
  101. variety of alphabet soup.
  102. It turns out that there's a threshold of complexity beyond which life becomes
  103. easier if you switch from shell scripting to a more robust language. Just
  104. where this threshold is located varies a lot between users and problems, but I
  105. often think about switching languages before a script gets bigger than I can
  106. view on my screen all at once. `addprop` is a good example:
  107. <!-- exec -->
  108. $ wc -l ../script/addprop
  109. 41 ../script/addprop
  110. <!-- end -->
  111. 41 lines is a touch over what fits on one screen in the editor I usually use.
  112. If I were going to add much in the way of features, I'd think pretty hard about
  113. porting it to another language first.
  114. What's cool is that if you know a language like C, Python, Perl, Ruby, PHP, or
  115. JavaScript, your code can participate in the shell environment as a first class
  116. citizen simply by respecting the conventions of standard IO, files, and command
  117. line arguments. Often, in order to create a useful utility, it's only
  118. necessary to deal with `STDIN`, or operate on a particular sort of file, and
  119. most languages offer simple conventions for doing these things.
  120. -> * <-
  121. I think the shell can be taught and understood as a humane environment, despite
  122. all of its ugliness and complication, because it offers the materials of its
  123. own construction to its users, whatever their concerns. The writer, the
  124. philosopher, the scientist, the programmer: Files and text and pipes know
  125. little enough about these things, but in their very indifference to the
  126. specifics of any one complex purpose, they're adaptable to the basic needs of
  127. many. Simple utilities which enact simple kinds of knowledge survive and
  128. recombine because there is a wisdom to be found in small things.
  129. Files and text know nothing about poetry, nothing in particular of the human
  130. soul. Neither do pen and ink, printing presses or codex books, but somehow we
  131. got Shakespeare and Montaigne.