ANSI Escape Sequences Disappear When Running a Ruby Script to Output to Geektool

Question

I am trying to use the OS X app GeekTool to print colorized text output onto my Desktop. GeekTool allows you to place little windows called "geeklets" onto the Desktop. One kind of Geeklet displays the output of a shell command.

My desired output should come from a text file that I am parsing with a ruby script. I am using the ruby gem colorize to add ANSI escape sequences around strings in Ruby. My goal is to output these strings to Geektool and display colorized text.

When I run the Ruby script in terminal (both Terminal and iTerm2, using both zsh and bash) the output is perfectly well-colorized. But when I run the script in GeekTool, it is not-- the escape sequences are not shown in the output, but there is no color. I know GeekTool supports ANSI escape sequences, because when I run this shell command:

printf "\e[0;35;49mabcd\e[0m"

I get colorized GeekTool output. echo $SHELL also tells me that GeekTool is using the same zsh executable I normally use. But for some reason, my ruby script will not print colorized output. Instead what I see is mono-color output, but with the escape sequences stripped.

My script uses Ruby's puts to output the strings containing the escape sequences. I tried switching to p. When run in the terminal, this yields non-colorized output with the escape sequences intact. When run in GeekTool, I also get non-colorized output, but the escape sequences have again disappeared.

Anyone know where my escape sequences are going?

Answer 1

I found a workaround for this problem. I needed to drop the colorized gem and "double escape" the escape sequences. I colored a string by wrapping it with strings like the ones below:

"\\e[0;36;49m"  # example color
"\\e[0m"        # clear

After building one large string containing many of these escape sequences, I did

command = "printf \"#{mystring}\n\""  # The trailing \n is needed to prevent Geektool from displaying [m at the end for some reason
exec(command)

This did the trick. It seems that the strings were being processed twice somehow in outputting to Geektool. The double backslash in front of the escapes \\e is needed to keep them from being consumed on the first pass.