Archive for August, 2012

A Bash Quicky

Thursday, August 30th, 2012

In our last episode spelunking a particularly shallow trough of bash goodness, we came across dollar sign substitution, which I said mimics some uses of regular expressions. Regex’s are often thought of as thick or dense with meaning. One of my more favorite descriptions goes something like, if you measured each character used in code for a regex in cups of coffee, you’d find the creators of this particular syntax the most primo, industrial-strength-caffeinated folks around. I’m paraphrasing, of course.

Now copy-pasta-happy, cargo-culting-coders like myself tend to find working code samples and reuse salvaged pieces almost without thinking, often recognizing the shape of the lines of code more than the underlying meaning. Looping back around to dollar sign substitution, we can actually interpret this commonly used value, assigned to a variable meaning the name of the script:
${0##*/}
Okay children, what does it all mean? Well, let’s start at the very beginning(a very good place to start):
${0}The dollar sign and curly braces force an evaluation of the symbols contained inside, often used for returning complex series of variables. As an aside, counting in programming languages starts with zero, and each space-separated part of the text is defined with a number per place in the order, also known as positional parameters. The entire path to our script is given the special ‘seat’ of zero, so this puts the focus on that zero position.

Regrouping quickly, our objective is to pull out the path leading up to the script’s name. So we’re essentially gathering up all the stuff up to and including the last forward slash before our scripts filename, and chuckin’ them in the lorry bin.
${0##*}To match all of the instances of a pattern, in our case the forward slashes in our path, we double up the number signs(or pound sign for telcom fans, or hash for our friends on the fairer side of the puddle.) This performs a “greedy” match, gobbling up all instances, with a star “globbing”, to indiscriminately mop up any matching characters encountered along the way.
${0##*/}Then we cap the whole mess off by telling it to stop when it hits the last occurrence of a character, in this case forward slash. And that’s that!

Pardon the tongue-in-cheek tone of this quick detour into a bash-style regex-analogue… but to reward the masochists, here’s another joke from Puppet-gif-contest-award-winner @pmbuko:

Email from a linux user: “Slash is full.” I wanted to respond: “Did he enjoy his meal?”

Basic iPhoto Troubleshooting

Wednesday, August 1st, 2012

iPhoto is one of those apps that pretty much just works. But there are a few tips and tricks that we’ve picked up along the way, that we’d like to share with you.

The first: any time you’re having iPhoto problems, create a test library. To do so, hold down the option key when opening iPhoto.

When iPhoto opens, instead of a list of all your pretty pictures, you’ll see a screen that lists all of the iPhoto libraries available and options to browse to one (Other Library), create a new one (Create New) and choose one in the list. Click Create New.

Choose a location to save your iPhoto library and a name (e.g. TESTTESTTEST) and then click on the Save button.

The new library is created. If your problems go away then you have now triangulated them to the library itself. If the problems do not go away, then try a new user account on the system to see if the issue is with the profile and if the problems still persist then try moving the library to a new computer and seeing if it opens.

Assuming that the problem is with the iPhoto library (it usually tends to be) then close iPhoto and back the database up immediately. Then, open it again, this time holding down the Command and Option keys. When iPhoto opens, it opens the iPhoto First Aid screen, very helpful with iPhoto library problems. There are four options in the list. The options include:

  • Repair Permissions: Repairs the permissions of objects (I’ve yet to see this fix a problem, but I’m sure it can as it’s there).
  • Rebuild Thumbnails: Delete the thumbnails for photos and recreate them.
  • Repair Database: Checks the database for any errors and resolves them if possible. I’ve rarely found an issue this step did not resolve.
  • Rebuild Database: Rebuild the database from the files and metadata that don’t involve the database. Use this as a last resort.

I usually start with the top and work my way down, but YMMV. Now, in the event that the database can’t be repaired you’re not totally screwed. There are a few little third party utilities that can do things to the iPhoto database, but in my experience if a repair doesn’t work then you might be in a jam. As with many Apple apps, the iPhoto Library is actually a bundle. Within that bundle are a number of files, including .db files and .data files, property lists, caches, a directory of Thumbnails, another of Previews and another of Masters. Corruption can be in any of these. The most critical element is the Master directory, where the original images are stored. While not desirable, you can delete (move, not delete) aspects of the iPhoto database from this directory and allow them to be recreated until you locate the actual bad elements and see what kind of data is stored in them.

Finally, backup is just a very important aspect of any computing environment. Provided you have a good backup, Humpty Dumpty can be put back together from all the .db and .data parts of the database, journals, caches and img files if need be. While restoring an iPhoto Library from a backup is not always desirable, it will usually beat having to redo the Faces, Locations, Tags and other metadata for all the elements that comprise iPhoto!