| < October 2007 | Matthew Loar > Blog | December 2007 > |
Russ released remctl 2.11, which includes the switch to remctl's IANA-assigned port of 4373.
I have updated the diff for my Windows port and built new binaries. In testing I managed to get it to crash under certain circumstances. As far as I could tell the crashes were due to more instances of malloc'd blocks being deallocated with gssreleasebuffer. Correcting this may require more significant changes to the code. These crashes only seemed to happen when the server returned an error response, so if you only issue successful commands, you should be fine. :)
UPDATE 2008-01-26: Yesterday my port came up in a discussion in comp.protocol.kerberos, so I was looking at this again. Using the same binaries, I was unable to get it to crash no matter what I did - successful commands, undefined commands, access denied, host unknown. I even ran it under a debugger looking for trace messages or caught exceptions - nothing. I tried it on both XP and W2k3. It's possible that my previous results were tainted by a broken Kerberos install or something.
How did I spend this lovely weekend? With the exception of Friday night, which was spent at my sister's watching a movie, I did almost nothing but write code the entire weekend. And I'd like to say that I was working on an uber-cool project that will end world hunger, save the whales and bring balance to the Force all at the same time, but in reality I was merely working on rewriting rwho in C++.
It is slightly more than that - I am simultaneously working on something I am calling libmel. My original goal was merely to wrap old, clunky C APIs (like sockets) in a nice C++ layer. It has evolved into a sort of portability layer - I currently have a unifed socket interface for both Windows and Linux. Of course, the sockets API is almost identical on both platforms, so it really isn't much of a feat. What would be slightly more impressive would be to have a common utmp interface. I already have the code in rwho for reading from the Terminal Services API, so it should be feasible.
But there must be something seriously wrong with me that I come home from a week of writing code at work and then spend the entire weekend writing code for personal projects. I really need to find a new hobby, preferably one that involves meeting people.
I guess I do have bowling. Tonight, in fact. Time to sleep.
So I was reading screen(1) last night, and I came across something in the section on screen titles which interested me:
Finally, screen has a shell-specific heuristic that is enabled by setting the window's name to "search|name" and arranging to have a null title escape-sequence output as a part of your prompt. The search portion specifies an end-of-prompt search string, while the name portion specifies the default shell name for the window. If the name ends in a ':' screen will add what it believes to be the current command running in the window to the end of the window's shell name (e.g. "name:cmd"). Otherwise the current command name supersedes the shell name while it is running.
If found this very interesting. I start mutt and irssi using the screen command, so their window titles are useful, but I usually end up with 3-4 windows all named 'zsh'. This would be an easy way to remedy that.
I use zsh's new fancy prompt theme system, so what I ended up doing was copying the stock theme file to my home directory and changing its name. But here's the guts of what I had to do:
screen_hack="%{^[k^[%}"
PS1="$screen_hack$base_prompt$path_prompt %# $post_prompt"
The ^[ are literal escape characters. Apparently the %{%} are important - if you exclude them, zsh will get very confused when you use tab completion. Try it and you'll see what I mean. Once you have done this, all that's left is setting the shelltitle in .screenrc:
shelltitle '% |zsh'
And voila! Magic auto window-titling. After that, I was reading the part of screen(1) that talks about what escape sequences screen recognizes, and I found something interesting:
ESC ] 83 ; cmd ^G (A) Execute screen command. This only works if multi-user support
is compiled into screen. The pseudo-user ":window:" is used to check the
access control list. Use "addacl :window: -rwx #?" to create a user with
no rights and allow only the needed commands.
Hmm! It struck me that this could be used for a lot of cool things, including an alternate way to do the titling. Since zsh has the very cool duo of precmd and preexec, it was relatively simple to set this up. .zshrc:
function precmd {
prompt_adam1_precmd
echo -ne "\033]83;title zsh\007"
}
function preexec {
local foo="$2 "
local bar=${${=foo}[1]}
echo -ne "\033]83;title $bar\007"
}
My precmd calls the function that my themed prompt, adam1, requires, as well as resets the title to zsh. The one sticking point was parsing out the part of the command I wanted. $2 contains the full command after alias expansion. However, by default zsh does not break variables into words, so $2[1] will be the first character of the command, not the first word. the ${=2} tells zsh to break foo into words on spaces. However, there's yet another trick: it won't do anything if $2 does not contain spaces. So that's why I add a space to $2 and call it $foo. And here's the .screenrc:
aclchg :window: -rwx #? aclchg :window: +x title
And there you are. This approach strikes me as a little cleaner, so I think it's what I'm going to go with. Plus, you can use this special escape for lots of cool other things. Right now I'm working on setting it up so that urlview will open lynx in a separate window, so that I can open links and then go right back to mutt. UPDATE: I just solved that last part for someone in comp.mail.mutt. It's as simple as putting the following in a .urlview:
COMMAND /bin/echo -e "\033]83;screen lynx -accept_all_cookies -vikeys %s\007"
UPDATE: Someone in comp.mail.mutt posted a much simpler solution to the later problem. You can accomplish the same thing with screen's -X option, like so:
COMMAND /usr/bin/screen -X screen lynx -accept_all_cookies -vikeys %s
This has the advantage of not requiring you to grant the :window: user access to the screen command.
Since this allows any process that can write to your terminal to start processes under screen, it could
be a potential security risk. So I would recommend using the latter solution.
| < October 2007 | Matthew Loar > Blog | December 2007 > |