Skip to content

“Expected identifier, string or number”

Thanks, IE.

I just spent pretty much all day tracking down the cause of this error. Conventional wisdom regarding this error is that you have a snippet of JavaScript like (where the comma trailing “42″ is the error):

var myObj = {
    a: "a string",
    b: 42,
}

I didn’t. But IE 8 was still throwing up this error message and its developer tools were pointing me at a line of HTML that contained nothing more than “<div>”. WTF, right? So after much confusion, and narrowing of code, I found the line IE was really barfing on. Consider the following object:

var myObj = {
    default: "ie blows",
    b: 42
}

Can you guess the problem? IE does not like keywords being used as the name of an object property. If you really want to use a keyword, like the jQuery plugin I’m using does, then write your object with JSON style syntax:

var myObj = {
    "default": "ie blows",
    "b": 42
}

Create A Daemon Out Of Any Program

I find myself having to write a script that does this sort of thing every time I have a need. I finally got fed up enough with that to write a generic script that can be used with any interactive program. The script can be found on my BitBucket site under the Scripts repository; the script is named screen_daemon.sh.

The script, as should be obvious, relies on the screen utility to manage the “daemon.” Screen specifically supports this type of thing with the “-Dm” switch combination. This switch combination starts screen in detached mode but doesn’t “fork a new process” (`man screen`). This means that screen starts whatever program you pass in and quits as soon as that program terminates. Thus, you can safely assume that the process id (pid) of the screen session is the pid of your daemon. On lines 82 – 84 of screen_daemon.sh I provide an example that takes advantage of this fact for programs that don’t write their own pid file.

If you create a daemon using this script, you can add a cronjob that runs your daemon script at regular interval, say every five minutes, to keep the daemon running. If the daemon is already running, the script will simply exit. If the script determines that an instance is not running, or has crashed in some way, it will start a new instance.

~/.ssh/config

~/.ssh/config is a file I have not had occasion to use until today. Evidently not many other people use it very often either, because finding the information I needed was more difficult than it should have been. Thus, this post is meant to make it easier to find.

I am currently hosting a private Minecraft server through redstonehost.com for a few friends. My hosting plan is a VPS specifically designed for easy Minecraft server administration. It being a VPS, I have direct SSH access to the server. The SSH account is pre-configured by RedstoneHost to a specific user that manages your Minecraft server. The password for this user is configured by you via your RedstoneHost user control panel. The password I configured is a complex, auto-generated, password.

Given that my password for the VPS is complex, I would rather use an SSH key file for authentication when I need to login. However, I do not want to use the same key that I use for other systems. This is where the need for the ~/.ssh/config file comes into play.

When you do `ssh james@example.com` the remote system sends a packet back telling your local SSH client what forms of authentication it will accept. If the remote server accepts key files, and you have your key configured with the remote host, it will attempt to validate your identity based on the keys installed in your ~/.ssh/ directory. Except, it doesn’t validate against just any key files in the directory. SSH2 specifically checks agains ~/.ssh/id_rsa and ~/.ssh/id_dsa before giving up on key file authentication and moving on to the next method. Thus, if you want to use a key file ~/.ssh/example_com_dsa you would need to do `ssh -i ~/.ssh/example_com_dsa james@example.com`. This is definitely more typing than anyone wants to do just to connect to a host.

To solve this problem, you can add the following to your ~/.ssh/config file:

Host example.com
    User james
    IdentityFile %d/.ssh/example_com_dsa

Now every time you do `ssh example.com` you will be connecting to example.com as if you had done `ssh -i ~/.ssh/example_com_dsa james@example.com` instead.

For more information on what options are available to you in the config file, read through the manpage. For some more examples of how the config file can be helpful to you, look through this ALE thread (Atlanta Linux Enthusiasts).

Sonar 2011 Remix Competition And My Re-emerging Hobby

I have entered the Sonar 2011 remix competition by Loopmasters with a track I’m calling Sonacid. It’s got a Wink style acid house vibe. This is my first public release since getting started with Ableton Live four months ago.

Which brings me to the second part of this post’s title. Before I truly committed myself to completing my degree, I spent a lot of time with music. After I completed my degree, I dabbled with music occasionally. I created some rather decent arrangements with Garage Band, but nothing I would consider totally original and worthy of getting published. Everything has changed in the past four months.

Ableton Live has brought back the desire in me to create original music. Music has once again become my primary hobby, and I have worked in Live almost every single day over the past four months. I have created several new tracks, a couple of which are fully complete, and I continue to learn and have fun with Live. But since Live isn’t some amatuer hour free tracker, I have opted not to release any of this material for free. My plan is to release my work via the UltraPhonix Recordings (UPR) label. In fact, my first release was scheduled to be sometime this month, but extenuating circumstances has delayed that plan.

So, until then, please enjoy a taste of my upcoming work with Sonacid. I am not making it available for download, hence it only being available for streaming on SoundCloud, just yet. After the competition results are posted, I might enable downloading of the track. But I might also wait and see if UPR would like to release it.

SSH User’s IP Address

Let’s pretend you need to write a script that should not be run more than once concurrently. Let’s also pretend that the script has the potential of being run by multiple people through the same account (wonderful security setup you have here). So you come up with the brilliant idea of making the script create a “I’m already running” file and check for it before continuing. If the file is already present, you decide that you want the script to tell the person trying to run it who is already running the script and quit. That’s a bit tricky when everyone is logged in as the same user; you can’t just output the username of the person running the script.  Everyone has a different IP address, though, so you can identify users by IP. So now you need to get the IP address of the person running the script. This is problem I had to solve.

Doing a little searching, I found a script using the who utility to solve this issue. The problem with that solution is that it relies on only one instance of the user being logged in. This solution doesn’t account for multiple IP addresses in the output. A little more searching and I found a great answer, but it doesn’t go all the way. So I expanded it into the following script (getIP):

#!/bin/bash

env_ssh_client=$(env | grep SSH_CLIENT | cut -d'=' -f2)

if [ "${env_ssh_client:0:1}" == ":" ]; then
    # IPv6 enabled
    # This is likely not nearly robust enough
    IP=$(echo ${env_ssh_client} | awk '{print $1}' | cut -d':' -f4)
else
    # IPv4 only
    IP=$(echo ${env_ssh_client} | awk '{print $1}')
fi

echo ${IP}

The script returns the IP address of the executing user. Pay attention to the comments. The system I’m using this on has IPv6 enabled, but uses dotted-quad notataion. Thus you might have to improve the script some for your own usage.