An Excellent Adventure

From BOFH to Devops in a million tiny steps

Syntax Highlighting in Sublime Text 2

It seems like this should be a pretty easy thing, but the existing documentation is not super clear (to me anyway), and it’s definately not inviting. But it seems like if I’m gonna use a fancy editor such as ST2, I should:

  • get syntax highlighting for the files I edit
  • understand how to add syntax highlighting for new file types
  • start learning the ins and outs of it.

An adventure in regex and obtuse documentation

Zone Files

I’m working my way through our zone files at $work, cleaning out the cruft of several generations of moving standards and moving the remains of old internal domains to the current domain. So having some syntax highlighting seemed like a far more interesting thing that actually doing the work. :D

Things to highlight

Some docs from Red Hat and IANA were helpful in identifying my list of things to highlight:

  • Comments
  • Directives
  • Resource Records
  • Time Units
  • MX Preference

Figuring Out Syntax Highlighting

Starting with Sublime Text documentation (old and new) on syntax highlighting, and a cheat sheet for ST2’s regex (ruby?).

Starting Easy

First I did comments, as that seemed like the easiest regex to not mess up.

Zone Comments
1
2
3
4
 "patterns": [
    { "match": ";.*",
      "name": "comment.line.semicolon.zone_file"
    },

Made sense, semicolon and everything to the end of the line is a comment. I had a little bit of trouble at first because I misread the ST doc writeup about naming, and named it something random. This would catch me a few times through this until I made myself a cheatsheet that I could keep open in another window.

Getting More Complex

The ‘@’ directive was another pretty straightforward match, and as the rest of the directives in a zone file are a pretty short list, I just shoved it all into the regex. Seemed to be an acceptable method of doing things (check out the html tmlanguage file for some crazy examples).

Zone Directives
1
2
3
4
5
6
7
8
9
 { "match": "@",
      "name": "keyword.directive.zone_file"
    },
    { "match": "\\$(ORIGIN|origin|TTL|ttl|INCLUDE|include)\\s*(.*)",
      "name": "keyword.directive.zone_file",
        "captures": {
          "2": { "name": "variable.other.directive.zone_file" }
         }
    },

So any directive is going to also have a variable. The way this gets dealt with for syntax highlighting is “captures”, in your regex you grab pieces of the match, the first will get named in the match, and all subsequent get named in the “captures” section. (Man, I can’t believe how not clear that sounds written out)

Captures get even more fun in this next bit

Zone Resource Records
1
2
3
4
5
6
7
8
    { "match": "([A-Za-z0-9-]*)\\s+([0-9A-Za-z]*)\\s+([I|i][N|n]\\s+[A-Za-z]+)\\s+(.*)",
        "name": "string.quoted.single.address.zone_file",
        "captures": {
            "2": { "name": "variable.other.timeunit.zone_file"},
            "3": { "name": "keyword.resourcetype.zone_file" },
            "4": { "name": "string.quoted.single.resource.address.zone_file" }
        }
    }

So the initial match, as well as the last are the hostname/ip in a typical A record, “2” is the ttl for a single record (doesn’t get used most of the time in my zone files, but I wanted to make sure it got colored the same as I did other time unit call outs). “3” is the ‘IN A’, ‘IN CNAME’, etc. I started going down a rabbit hole of actually correctly calling out of the resource types, but then realized that was far more work than necessary.

Sharing

It’s on github, pull requests gladly accepted. Is this worth trying to get listed in Package Control? Seems unlikely.

Next Steps

The easy plan is to work on other config files I look at regularly. The harder plan is to expand past syntax highlighting and get into tab completions and shft-cmd-p creation of zone file templates and such.

Hello World

A New Hope Beginning

Here begins the documenting of my attempts at both staying current and relevant in the rapidly changing world of operations. Devops is the new thing. I am a bit of an old guard BOFH, even if I never quite bought into the BOFH attitude.

Blarggy Blahg

This blog runs on octopress (itself a ‘framework’ running atop jekyll), pretty much bog standard. I like that I’m using my current fav text editor (Sublime Text) rather than a web based text entry window.

Things I’m hoping to gain by this:

  • comfort with writing in markdown
  • more interaction with ruby
  • noodling for the sake of noodling.

Devops?

So, yeah, this devops thing. It’s interesting, I’m excited by it, and challenged to step up my scripting/coding chops.

Also, I’m trying to move a very old school dev vs ops culture to more of a devops style place. I’ll be documenting that attmept here too.

Whut?

nothing.