Wednesday, January 19th, 2005


I had noticed my iMac 1.25 GHx slowing down. Here’s what sped it up most:

  • Getting more RAM. I upgraded from 256 Mb to 768 Mb. Applications loaded faster, particularly when lots of them were already running. Especially noticeable when other users were still logged in.
  • Cleaned Application cache. Using System Optimizer X I was able to do this, which while it makes each application pop up a dialog the first time it is run via a double-click on a document, fixes corruption in the Application Cache, enabling applications to load much faster. This includes the Finder, so it only takes seconds (instead of minutes) to log in.
  • Update executable library prebindings. Since this too was done with SOX, I wasn’t able to tell which of these two made the biggest difference.

No, I’m not affiliated with SOX, and apparently it’s possible to do just about everything here with CLI commands, I just don’t know what they are yet…

View Comments (0)   RSS Feed for Comments on this Post

I have a few aliases and functions running in my ~/.profile, and some of them run MacOSX applications - for instance I like to edit files in SubEthaEdit, but I like to just use the word edit as the command to start the process. This is all well and good, until I’m remotely accessing a command line only, and try to edit a text file.

If I’m logged into the Mac, up pops SubEthaEdit, and if I’m not logged in, I see

kCGErrorRangeCheck : Window Server communications from outside of session allowed for root and console user only INIT_Processeses(), could not establish the default connection to the WindowServer.Abort trap

Not much fun at all.

So I wrote a function that will run the right program if I am remotely logged in. I found that Terminal sets the environment variable TERM_PROGRAM to 'Apple_Terminal'.

function edit
{
  if test `echo $TERM_PROGRAM` == 'Apple_Terminal' ; then
      open -a 'SubEthaEdit.app' "$*" &
  else
      pico "$*"
  fi
}

So far so good. But when I exit pico from my other terminal, I see an error of:
-bash: test: ==: unary operator expected

What’s happening is that the `echo $TERM_PROGRAM` is displaying “” (empty string) which test doesn’t like on the left hand side of a “==”.

So the first lines of my ~/.profile are now:

if test `echo $TERM_PROGRAM""1` == '1' ; then
 export TERM_PROGRAM='Unknown'
fi

This took me a while to twig to - for ages I was just happy to have the error appear!

The only issue with this is if I telnet from my imac (where the variable is set) into the same machine - you then lose the ability to automatically run the graphical programs set up in the functions.

The other programs I use differently according to where I am are:

  • appswitch - use as a replacement for ps, kill, and to show/hide running programs.
  • SubEthaEdit - use as edit, and sedit (edit as Super User).
  • openman - a new window for each man page, allowing them to stay open while I keep working.

I also have a function called browse, that opens the current (or supplied) directory in the Finder. I’d love to be able to tell Windows Explorer to open this, but this would require some heavy duty inter-machine communication.

View Comments (0)   RSS Feed for Comments on this Post

I sometimes have to use the PC next to my imac, and when I want to start a shell session, I use PuTTY. Now, usually I have to go through the process of either filling in the address of my mac, or click on the profile and load it, before clicking open.

However, it’s possible to just edit the Windows Shortcut, and add the name of the server (or IP address) after the Target: information. Make sure the server name or address is not inside the quotes, and there is a space between them.

Now, double-clicking the shortcut will connect to the server.

It’s also possible to connect to a different port number.

Update: If I’d read the FAQ, I’d know you can also use a -load mysessionname switch to load all of the settings from a saved session. Now if I could just get MacOSX telnetd to accept environment variables from the telnet client!

View Comment (1)   RSS Feed for Comments on this Post