Double click for new terminal

I’m completely dumb at the Apple-way-of-scripting. I wanted something I could throw on my desktop that I could double click and it would open a terminal window and ssh somewhere. I’m not sure how useful this will actually *be* to me, but given it took me non-zero time with google to figure it out… thanks to various stackoverflow posts.

Open Applescript Editor. Put in:

tell application Terminal
do script "ssh hostname"
set bounds of front window to {63, 640, 1212, 1022}
end tell

File | Export … and save it as an application. Put it on your desktop, giving it a reasonable name. Done. If you want to later edit the script (say, to set boundaries :) ), right click, Show Package Contents, then go into Contents\Resources\Scripts and edit the main.scpt file you’ll find. The “set bounds” statement places the window at the bottom-left-ish and makes it 160×25 at my current resolution and font size. I can’t figure out how to tell Terminal to just set itself to 160×25 without also moving it, and I expect that the actual characters displayed depends on font, size, etc.

Making usable

Thunderbird finally drove me over the edge. Might have been that whole “no new features OH HEY YOU CAN IRC FROM YOUR MUA” – guys, if I wanted emacs, I’d use it.

I used to care a lot about Enigmail. For various reasons, I care less about it now. There are, however, a few things that I would miss about it. Oddly, the one that I kind of missed the most is the most whimsical – I like having my default signatures rotate. So I did a bit of digging, and came up with some applescript (courtesy‘s post on the subject) only slightly modified.

Also, being a complete Mac-centric scripting n00b, I wasn’t sure how to make things go. Save the Applescript into a file called… anything. Run osacompile against it. You can call the resulting compiled script from your .bashrc with osascript, something like

osascript /Users/foo/bin/sigrot.scpt

Another relatively minor irritation is the default behaviour of never marking mail as read, or marking it as read instantly. You can theoretically fix that with

defaults write MarkAsReadDelay 4

but that didn’t work for me (10.8.1). Instead, I used TruePreview.

Now, if only I could convince it to show me messages most recent at the top, but when they’re threaded, show them most recent at the bottom.

Documentation and maturity

There are three stages of maturity when it comes to getting things work and documenting how you did it.

1) I got it working, hurray! Run away before it breaks.

2) I got it working, hurray! And I took notes while I was getting it working, so I’m good. Run away before it breaks

3) I got it working, hurray! And I took notes while I was getting it working, so I’d better start from scratch and make sure my notes work.

chkconfig, mysql

A crash today brought home a couple of things that I should have known before but didn’t, and now I do. I’m writing them here so I don’t forget, but also because google results were annoyingly useless without digging.

#1: chkconfig. That funny line in the init script that says something like “# chkconfig: 23456 88 22”. It’s easy to find out that the first batch of numbers is runlevels, but less easy to find out the meaning of the second set. They’re priorities; the higher the first number, the later in the boot process it starts. The higher the second number, the later in the shutdown process it’s killed. Also, if you change those numbers – this is obvious in retrospect, but I forgot – you need to re-run “chkconfig on servicename”.

This is apparently all defined in the LSB. Back in my day, there was no that thur LSB, never mind chkconfig. You just put scripts in /etc/rc.d and crossed your fingers.

#2: misamchk. This worked fairly well on my 72GB RAM server with a ~25GB database:

myisamchk --fast --update-state --force --sort_buffer_size=1G \
--key_buffer_size=2G --read_buffer_size=512M --write_buffer_size=512M \

The myisamchk manpage talks about “a lot of memory” being 512M so obviously it could use a bit of modernizing. That, or it really is MyFirstDatabase.

And this kind of stuff reminds me that while I need to keep my hand in, I’m just as happy to no longer be a sysadmin for a primary job duty.

(Edited Aug 2012 – neither should typing be, chkconfig on, not chkconfig start.)

Using Stow on a Mac

For various reasons, I build some utilities outside of things like MacPorts and Brew, mostly interpreters where I want to ensure that my environment is my environment. I need all of Python, Ruby, and Perl, and sometimes different versions of Ruby as well.

Normally I build with –prefix=$HOME/app/name-maj.min then link app to whatever version I want to be the default. In $HOME/bin I make links to $HOME/pkg/app/bin and mostly everything just works. Except then I started running into problems with man pages, and setting this environment up can be a pain in my login shells. So I went looking for something that automated this. There’s just no other sensible way to do this on a Unix system.

By the way, at (the University of) Waterloo we have a(n) (in)famously obtuse packaging / configuration management system called xhier. Any time I think about this, I wish I had the GOOD parts of said system available. It has lots of nifty toys to automate building, configuration, and managing links, as well as a utility called showpath that helps you to manage both your PATH and MANPATH variables. And I’ve often declared that anybody who thinks about automating, including things like Stow, is at risk of re-inventing xhier.

Stow is a bit of an annoyance in that it, itself, requires Perl. The entire reason I like having my own separate Perl instance, in particular, is because of a long history of CPAN screwing me over. So I put my own version aside, run CPAN, and no operating system update blows my stuff away, and no CPAN will touch my OS stuff. I tried the MacPorts version of Stow and just couldn’t make it cooperate in integrating into my above flow – it would make links just fine in $HOME/stow, but it wouldn’t remove apps.

What finally worked was using my own $HOME/pkg/perl CPAN utility to install Stow. Then I was able to:

cd ~/pkg
stow -t ~/stow ruby-1.9.3
stow -D -t ~/stow ruby-1.9.3

and everything seems to work as expected. The above did not, with the MacPorts version, but it’s still at 1.3 and perhaps there’s issues with the older version, I don’t know. I don’t really like Perl very much any more, so I’m not inclined to delve into the whats wherefores and whys. I thought about looking at how the MacPorts version differed (in configuration) from mine, but then I cracked another beer, drank it and a few more, then laid down for a while and the feeling passed.

(Edited to account for Giles’ grammar correction and general persnickitiness. Thanks, Giles!)