Wednesday, May 4
Back in Colorado, the lawn needs mown and the sink is full of dishes. Last Tuesday morning’s old-computer build is still half-assembled on the kitchen floor and the kitchen counters and probably several other places.
✦
There are a bunch of things I should be doing (like the dishes), but I was just dorking around with some pointless shell script instead.
It got me thinking about how it’s too hard to write little shell utilities. Two categories of reason for this:
First, the existing shells are bad as general-purpose programming languages.
- The simple things you want from a language are either missing or really hard to get.
- The syntax is hideous and everything is riddled with edge cases which will bite you or your users.
- Patterns exist to help with some of this, and conscientious authors will be aware of them, but they are inconsistently applied, made of illegible boilerplate, and often a matter of unevenly-distributed folklore.
- I’ve evidently been harping on this one for a while.
Second, general-purpose language environments are bad at the stuff I want when I write shell utilities.
- Argument handling is miserable and full of boilerplate.
- Doing things to files and directories is way harder than it should be.
- The “correct” abstraction around a given task is often much harder to use than the corresponding shell utility would be.
- The best available library often introduces a new (and sometimes unstable) dependency.
- Reusing other parts of the shell environment is often fraught with hazard, or at least silliness.
I don’t want to claim these plaints are universals, exactly.
There are glue-language features in Perl which keep me coming back for little
one-offs that wind up in my ~/bin/. I wrote a thing in Python the other day
using docopt to handle arguments, and hey, really, not too shabby.
Despite its problems, there are encouraging things about some of the patterns
I see used in Node.js.
I would, however, still like to see an improved toolset for the conceptual space of “little things you use at the command line”.
☼
I learned the other day that you can do this:
brennen@exuberance 21:45:01 /home/brennen ★ cal -3
2016
April May June
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 1 2 3 4 5 6 7 1 2 3 4
3 4 5 6 7 8 9 8 9 10 11 12 13 14 5 6 7 8 9 10 11
10 11 12 13 14 15 16 15 16 17 18 19 20 21 12 13 14 15 16 17 18
17 18 19 20 21 22 23 22 23 24 25 26 27 28 19 20 21 22 23 24 25
24 25 26 27 28 29 30 29 30 31 26 27 28 29 30
…which will show the months before and after the current one.
I don’t know how I made it this long without knowing about that option.
There’s a generalized approach, too, with -B n and/or -A n for n months
before and after the current month.