So, things are going pretty well with Wget. We just had our mid-term evaluations for the Google Summer of Code project. Our two GSoC students are right on-schedule with where they’d promised to be at this stage. Both of them had exams during the first portion, so the level of work they were supposed to get done was somewhat scaled down from what it would otherwise have been; still, it’s nice that there haven’t been any real difficulties, and things are coming along alright.

Also, the copyright assignment paperwork came through for a batch of changes that adds CSS support to Wget, so I’m excited about that. I haven’t gotten much done for my part, though. Been pretty busy.

I recently joined the GNU Screen project, as a co-maintainer, to help get things moving towards a next release. If you haven’t heard of Screen, I can’t really explain it in detail here: it’s sort of a special-interest thing. But, if you spend a lot of time using command-line/terminal programs, screen is a huge asset. Especially if you use them remotely.

Basically, what Screen does is act as a sort of reattachable, “pretend” terminal. I say “pretend” because, while it is a fairly full-featured vt100 terminal emulator, it’s missing a crucial component that most terminal emulators have: it doesn’t actually draw text to a screen. It interfaces with whatever “real” terminal emulator you’re running, and tells it what it should draw.

The nice thing about screen is that you can detach from it, and later reattach to it. If you lose your ssh connection, say, then you can simply log in again and attach to the same screen session you were running; none of your programs have to get killed due to a terminal hangup. Also, you can be attached to the same screen session from multiple terminals simultaneously. I do everything at work in screen; then when I come home, I can just ssh in and keep working on the same session. I can leave a build running, and then come home and check on its progress. You can even do more exotic things, like allow multiple users to use the same terminal session (mostly good for demonstrating how to do something).

My priority’s still with Wget, though, and I’ve made it clear to folks that while I’m happy to help out with organization and patch-integration, etc, I need to dedicate most of my free-time coding to Wget. I expect to be able to handle small patches and the like; but I have too much to do already with Wget. However, my work on Wget has ended up taking a sort of hiatus for a couple weeks, while I’ve been organizing some things (bug lists, mainly) at Screen; also, I’ve been spending most of that time coding a program I’ve always meant to write, but which has now become incredibly useful as a tool for debugging issues with Screen.

It’s a program that analyzes terminal escape sequences. These are special commands that are sent as part of the text stream to the terminal, to tell it to do something special. For instance, in Unix-like systems you could print a red-and-green “Merry Christmas” to the screen by issuing the command:

The “gibberish” in there are the special commands that tell the terminal how to color the output. Each bit of gibberish starts with \033, which is a numeric code representing the escape character. If you run the above command, you’ll get output like:

It’s not too bad to look at and analyze a string like the one I gave to printf above; but when you have a whole bunch of funky gobbledy-gook like that to sift through, it helps to break it down. The tool I’ve been working on lately would take that same string, and give this output:

It gives a breakdown of the text it sees, the escape sequences, what control function they represent, and what the actual effect they produce is. This makes it a lot handier to see what’s being sent to the terminal when not everything’s working as it should.