Listing Terminal Colors

If you’ve ever worked with colors in a modern terminal emulator you may occasionally find yourself looking for just the right index to use in its standard 256-color palette. The other day I was in the same situation, so I wrote a little Bash script to print a pretty preview of all the colors. Here’s some sample output from Terminal.app (using the “Novel” profile):

Not bad! Now you could just download the script and call it a day, but what’s the fun in that? 😊 If you’re game, let’s take a few minutes to go through the code together and figure out how it works…

First, we write a function to print each color index:

 7padding="   "
 8
 9print_index () {
10  index=$1
11  printf "%s%s" "${padding:${#index}}" " $index "
12}

On line 7, we create a new string (padding) of three whitespace characters. On line 10, we set the variable index equal to the first parameter ($1). Finally, on line 11, we print the index padded to a width of five characters. The result is right-justified, with a single space to the right of each index.

The syntax for the padding is a bit obtuse, so let’s break it down:

• ${variable} is a more explicit way of writing $variable, and simply returns the value of the given variable.
• ${#variable} returns the length of the given variable. Because Bash variables are just character strings, this returns the number of digits in the index.
• ${variable:offset} returns the value (substring) of the given variable starting from the specified offset.

So ${padding:${#index}} returns a string with the number of whitespace characters in padding less the number of digits in index. More specifically, this expression returns two whitespace characters if index has one digit; one whitespace character if index has two digits; and an empty string if index has three digits.

(For more details on this syntax, see the section on parameter substitution in the Advanced Bash-Scripting Guide.)

Next, we write a function to print each color:

14lut="\e[48;5;"
15reset="\e[0;39;49m"
16
17print_color () {
18  index=$1
19  printf "${lut}${index}m ${padding} ${reset}"
20}

On line 14, \e[48;5; is the start of an ANSI escape sequence, where

• \e[ is equivalent to the ESC ASCII control code (decimal value 27);
• 48 is the Select Graphic Rendition (SGR) parameter to set the background color; and
• 5 indicates that we are using a 256-color lookup table.

Similarly, on line 15, \e[0;39;49m is an SGR control sequence that resets all display attributes (0) before setting the default foreground (39) and background (49) colors.

(Note that the numbers in an SGR sequence are separated by semicolons and that a valid sequence must end in the ASCII character m.)

On line 19, we bring this all together to display a color patch. Building on the explanation above, we can describe what the expression ${lut}${index}m ${padding} ${reset} does as follows:

• ${lut}${index}m expands to \e[48;5;${index}m, selecting the color at the given index from a 256-color lookup table.
• ␣${padding}␣ expands to five whitespace characters (the width of the color patch).
• ${reset} expands to \e[0;39;49m, resetting all display attributes along with the foreground and background colors.

Now that we have our plumbing in place, let’s print the eight standard colors (indices 0–7) on a single line:

26bold="\e[1m"
27
28printf "\n${bold}Standard colors${reset}\n\n"
29for (( n=0; n<8; n+=1 )) ; do
30  print_index $n
31  print_color $n
32done

(Note that we’ve introduced a new SGR control sequence, \e[1m, to make the heading text bold.)

We can print the eight “bright” colors (indices 8–15) the same way:

38printf "\n\n${bold}Bright colors${reset}\n\n"
39for (( n=8; n<16; n+=1 )) ; do
40  print_index $n
41  print_color $n
42done

Next, let’s print the 216 colors (indices 16–231) in the middle of the lookup table:

46printf "\n\n${bold}Colors #16-231${reset}\n"
47for (( n=16; n<232; n+=6 )) ; do
48  (( (n-16) % 36 )) || echo ""
49
50  for i in {0..5}; do
51    print_index $(( n+i ))
52    print_color $(( n+i ))
53  done
54
55  echo ""
56done

216 colors won’t really fit on a single line, so we’ll take the fact that they are arranged in a 6x6x6 “cube” into consideration and print them in 6x6 blocks, instead. We iterate through the indices six at a time (line 47), adding an extra space before each 6x6 block (line 48) and printing each index followed by a patch of its corresponding color (lines 50–53).

Finally, let’s print the 24 grayscale colors (indices 232–255):

60printf "\n${bold}Grayscale colors${reset}\n\n"
61for (( n=232; n<255; n+=6 )) ; do
62  for i in {0..5}; do
63    print_index $(( n+i ))
64    print_color $(( n+i ))
65  done
66
67  echo ""
68done

Once again, 24 colors won’t really fit on a single line, so we iterate through the indices six at a time (line 61), printing each index followed by a patch of its corresponding color (lines 62–65).

And that’s it! I hope you found this post to be helpful and/or edifying. Once again, you can download a copy of the script to use and modify as you see fit. Have a question or comment? Feel free to get in touch on Twitter or by email.

Happy coding! 👋

Increasing Discourse's maximum attachment size

I recently wanted to allow larger files to be uploaded to my private Discourse site (running v1.2.0.beta1). It was easy enough to find the option that I needed to update—max attachment size kb—but I didn’t know what to make of the following warning:

The maximum attachment files upload size in kB. This must be configured in nginx (client_max_body_size) / apache or proxy as well.

How should I go about configuring this in nginx?

Read more…

Hosting Multiple Domains With Linode

I wanted to host a second website on my Linode recently. Rather than look up the process for doing so again when/if I decide to host a third website on the same Linode, I realized that I should just write up my own quick start guide for future reference. I am posting it here on my blog because I assume that it will be useful to someone else, too. (When in doubt, make it public.)

Note that although I am explicitly writing about how to add a website to a Linode running Ubuntu, you should be able to use most of these instructions on any Ubuntu server. In fact, I’m not even going to explain how to use Linode’s control panel here—I will only provide command-line instructions.

Read more…

TEPCO's Game of Whack-a-Mole

When I first read that Japanese government officials had denounced the Tokyo Electric Power Company (TEPCO) by drawing an analogy between its Fukushima cleanup efforts and a game of whack-a-mole, I have to admit that I initially enjoyed a bit of schadenfreude at TEPCO’s expense. It’s refreshing to see a company that has caused so much disruption to Japanese families finally get some kind of comeuppance—even if only in the form of a mild verbal lashing.

Once I got over my knee-jerk reaction, however, it gradually dawned on me that this is actually quite a boon for TEPCO. Bad press over the utility’s incompetence doesn’t change the fact that TEPCO’s plants power a third of Japan. Consumers are stuck with TEPCO whether they like it or not. We may laugh at the analogy between TEPCO and children playing whack-a-mole, but I imagine that the TEPCO executives are laughing too—all the way to the bank. In fact, they must be overjoyed that the government has decided to step in and take over the cleanup efforts, because this means that the financial burden of cleanup has been shifted from TEPCO to the Japanese taxpayer (in much the same way as the losses sustained by the U.S. financial system in 2007 were ultimately borne by the U.S. taxpayer). Furthermore, any failures in the cleanup effort will now be blamed on the Japanese government instead of TEPCO.

I can’t help but think of the following Calvin and Hobbes comic.

“If you do the job badly enough, sometimes you don’t get asked to do it again.”

Indeed.

Git Tip of the Day: --color-words

I’ve always felt that Git’s default diff output left something to be desired, especially when it was applied to Markdown text files (like the ones used to generate this blog). Line-by-line diffs aren’t very helpful if every line represents a paragraph of text.

I was thus pleasantly surprised to stumble across this blog post, which—among other things—explains how to generate word-by-word diffs that wrap nicely. The first step is to configure the default Git pager to wrap lines using one of the following commands.

git config --global core.pager less -r
git config --global core.pager "less -+\$LESS -FRX"

The second step is to tell Git to generate a (colored!) word-by-word diff with the --color-words option.

git diff --color-words

And that’s all there is to it! Note that --color-words is technically equivalent to --word-diff=color, so if you’re interested in reading about the other available options to --word-diff you can check out the git-diff man page.

As helpful as this technique is, there is one caveat to keep in mind: as far as I can tell the --color-words option only works with the git-diff and git-log commands. If you happen to use git add -p to stage individual changes—like I do—you are stuck with the default line-by-line diff output of git-add. That’s really only a minor inconvenience, though, because you can still call git diff --color-words just before git add -p to get a nicely-formatted overview of your changes before you stage them.

I hope you found this tip to be as helpful as I did!

Nintendo 2DS

I don’t know what to think of the Nintendo 2DS. First of all, it has a clever yet strange name: as an overlapping combination of “2D” and “DS” (“dual screen”), it pretty much describes a system in the original Nintendo DS series rather than one in the Nintendo 3DS family (as the Nintendo 2DS is officially being marketed). I wonder if this is a sign that Nintendo is preparing to replace their existing Nintendo DS lineup—the Nintendo DSi and Nintendo DSi XL—with the Nintendo 2DS? That would seem to make more sense than simply releasing a new version of the Nintendo 3DS at a lower price point. After all, at $129.99 the Nintendo 2DS is only $40 cheaper than the Nintendo 3DS ($169.99).

Then again, if the Nintendo 2DS is indeed going to be the spiritual successor to the Nintendo DSi, why will the system be conspicuously absent in Japan? (As far as I can tell, the Nintendo 2DS has only been announced for sale in the Americas and Europe.) The reasons behind this decision are still mysterious to me, but if I were to hazard a guess it would be that the Nintendo 2DS appeals to the price-conscious sensibilities of Americans (and apparently Europeans) rather than the quality-conscious sensibilities of Japanese people. Furthermore, Nintendo’s brand awareness is very strong in Japan and thus the company may not need to constantly reduce prices in order to sell its products. Still, I wonder whether the $40 price difference between the Nintendo 2DS and the Nintendo 3DS is really significant enough to drive sales.

So all that being said, how does the Nintendo 2DS really stack up against its Nintendo 3DS brethren?

Read more…

Calculating Git SHA-1 hashes in Ruby

Although the process by which Git calculates SHA-1 hashes is well documented in Pro Git, I had a hard time finding it today and decided to write a blog post that will (hopefully) be a bit easier for myself and others to search for later.

First of all, use the hash-object command as follows to print the SHA-1 hash that Git calculates for an object. (You can also pass a filename as an argument to hash-object.)

$ echo 'test content' | git hash-object --stdin
d670460b4b4aece5915caf5c68d12f560a9fe3e4

Note that, by default, echo prints a trailing newline character so this command is actually computing the SHA-1 hash of "test content\n". Interestingly enough, though, if you try to reproduce this behavior in Ruby by computing the SHA-1 hash of the same string, you get a different result.

$ irb
>> require 'digest/sha1'
=> true
>> puts Digest::SHA1.hexdigest "test content\n"
4fe2b8dd12cd9cd6a413ea960cd8c09c25f19527
=> nil

The reason for this, as explained in Pro Git, is that Git actually prepends the following information to a file’s contents before it calculates a hash.

1. The object’s type—blob for a regular object, tree for a tree object, and commit for a commit object
2. A space
3. The (human-readable) number of bytes of data in the object
4. A null byte (\0)

In other words, you need to run the following command to generate the appropriate hash.

$ irb
>> require 'digest/sha1'
=> true
>> puts Digest::SHA1.hexdigest "blob 13\0test content\n"
d670460b4b4aece5915caf5c68d12f560a9fe3e4
=> nil

Hope this helps!