It is my opinion that every developer should dabble in making their own scripting language at least once. Not to actually use, mind you, but to simply to learn how languages work. If you do find yourself building a system that needs to be extendable via scripts, don’t use your own language, but use a well understood and well-proven embeddable scripting language.

Which is why Neil spends a lot of time looking at Tcl. Tcl is far from a dead language, and its bundled in pretty much every Linux or Unix, including ones for embedded platforms, meaning it runs anywhere. It’s also a simple language, with its syntax described by a relatively simple collection of rules.

Neil’s company deployed embedded network devices from a vendor. Those embedded network devices were one of the places that Tcl runs, and the company which shipped the devices decided that configuration and provisioning of the devices would be done via Tcl.

It was nobody’s favorite state of affairs, but it was more-or-less fine. The challenges were less about writing Tcl and more about learning the domain-specific conventions for configuring these devices. The real frustration was that most of the time, when something went wrong, especially in this vendor-specific dialect, the error was simply: “Unknown command.”

As provisioning needs got more and more complicated, scripts calling out to other scripts became a more and more common convention, which made the “Unknown command” errors even more frustrating to track down.

It was while digging into one of those that Neil discovered a special intersection of unusual behaviors, in a section of code which may have looked something like:

# procedure for looking up config options
proc lookup {fname} {
  # does stuff …
}

Neil spent a good long time trying to figure out why there was an “Unknown command” error. While doing that hunting, and referring back to the “Dodekalogue” of rules which governs Tcl, Neil had a realization, specifically while looking at the definition of a comment:

If a hash character (“#”) appears at a point where Tcl is expecting the first character of the first word of a command, then the hash character and the characters that follow it, up through the next newline, are treated as a comment and ignored. The comment character only has significance when it appears at the beginning of a command.

In Tcl, a command is a series of words, where the first word is the name of the command. If the command name starts with a “#”, then the command is a comment.

That is to say, comments are commands. Which doesn’t really sound interesting, except for one very important rule about this vendor-specific deployment of Tcl: it restricted which commands could be executed based on the user’s role.

Most of the time, this never came up. Neil and his peers logged in as admins, and admins could do anything. But this time, Neil was logged in as a regular user. It didn’t take much digging for Neil to discover that in the default configuration the “#” command was restricted to administrators.

The vendor specifically shipped their devices configured so that comments couldn’t be added to provisioning scripts unless those scripts were executed by administrators. It wasn’t hard for Neil to fix that, but with the helpful “Unknown Command” errors, it was hard to find out what needed to be fixed.

[Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!