How many times have you had to go to a specific directory to launch an application or set several environment variables for an application to be able to find itself and run?  Well, here’s a simple trick to add to your shell scripts so that they’re self-contained with no external requirements or editing.

Trick

Put the following code in the top of your scripts and they’ll set your working directory to the directory in which the script actually resides.  This way, you’ll have a known base directory from which to call any other commands.  This also makes your launch scripts portable to other systems and directory structures without having to edit them to set a new directory or add new environment variables.

For *nix platforms: (this works in sh and bash)

#Get the fully qualified path to the script
 case $0 in
     /*)
         SCRIPT="$0"
         ;;
     *)
         PWD=`pwd`
         SCRIPT="$PWD/$0"
         ;;
 esac
 # Resolve the true real path without any sym links.
 CHANGED=true
 while [ "X$CHANGED" != "X" ]
 do
     # Change spaces to ":" so the tokens can be parsed.
     SCRIPT=`echo $SCRIPT | sed -e 's; ;:;g'`
     # Get the real path to this script, resolving any symbolic links
     TOKENS=`echo $SCRIPT | sed -e 's;/; ;g'`
     REALPATH=
     for C in $TOKENS; do
         REALPATH="$REALPATH/$C"
         while [ -h "$REALPATH" ] ; do
             LS="`ls -ld "$REALPATH"`"
             LINK="`expr "$LS" : '.*-> (.*)$'`"
             if expr "$LINK" : '/.*' > /dev/null; then
                 REALPATH="$LINK"
             else
                 REALPATH="`dirname "$REALPATH"`""/$LINK"
             fi
         done
     done
     if [ "$REALPATH" = "$SCRIPT" ]
     then
         CHANGED=""
     else
        SCRIPT="$REALPATH"
     fi
done
# Change ":" chars back to spaces.
REALPATH=`echo $REALPATH | sed -e 's;:; ;g'`
# Change the current directory to the location of the script
cd "`dirname "$REALPATH"`"

For Windows platforms:

Surprisingly, for Windows DOS there’s a much easier way to do this — just add the following to the top of your batch file.

cd %~dp0%

Happy scripting!

No, we’re not talking about the critter.  We’re talking about the fast open source searching tool by Dave Balmain.  You know, Ferret.  If you need fast indexing and searching, especially if you’re doing Ruby on Rails development, check it out.

Anyway, there’s one funky thing that we’ve come across lately and wanted to share — something that works well when running in development mode but that causes bizarre issues in production mode.

If you’re doing a search like this

query = Ferret::Search::WildcardQuery.new(:name, "tomcat")

it works just fine in development mode, but it’ll fail in production mode.

Trick

Why, you ask? Well, it turns out that in production mode Ferret uses something called DRb (Distributed Ruby) so that it can run as a stand-alone server to work with multiple Rails instances as clients. You can think of DRb as being similar to RMI if you’re from the Java world.

The key is that it has to marshal objects from once instance of Ruby to another, and then un-marshal them in the receiving instance to make them usable again. If the receiving instance doesn’t know about things like Ferret::Search::WildcardQuery you’re out of luck.

What’s so painful about this particular issue is that the error you get when the problem occurs looks like this:

DRb::DRbConnError (DRbServerNotFound):

followed by a giant stack trace.

Server not found? Excuse me? Not exactly what we were expecting.

To make a long story short, there’s an easy way to make all this pain go away, and that’s by simply using FQL, Ferret Query Language, to specify your search.

Instead of creating a WildcardQuery object, you can just define your search the easy way by saying:

query = "name:*tomcat*"

Wow, that sure was easy. Too bad that trying to save some parse time by constructing the object yourself leads to so much aggravation. This way, DRb only has to send a simple string across the wire and all is well.

Maybe next time we’ll just start with the easy solution and see how that works for a change.

We’d like to share a fix for something that has been driving us insane on an Ubuntu Fiesty box (though don’t think it’s at all limited to that distro). This fix may be common knowledge, but, if, like us, you’ve not heard about it, seriously, how common can it be, eh?

The box in question is a 500G Maxtor USB drive used as a backup drive for a Dell pizza box running Ubuntu Fiesty. We formatted it ext2, got it mounted, ran backup data to it, no problems. We made a daily cron job to do backups, but every morning when we reviewed the cron notifications, we’d discover that the backup failed because the file system was read-only which is not how we left it.

We’d log in, try to make a file on the backup drive and sure enough, couldn’t because it was read only. We’d unmount it, then remount it and it would be fine. By the next morning it was read-only again.

We reformatted the drive to ext3, reiserfs…no matter what: problems. Looking at log messages we’d see things like this:

Nov 19 07:29:54 hurricane kernel: [724306.332761] sd 4:0:0:0: Device not ready: : Current: sense key: Not Ready
Nov 19 07:29:54 hurricane kernel: [724306.332771] Additional sense: Logical unit not ready, initializing command required
Nov 19 07:29:54 hurricane kernel: [724306.332781] end_request: I/O error, dev sdb, sector 10706
Nov 19 07:29:54 hurricane kernel: [724306.332785] printk: 4 messages suppressed.
Nov 19 07:29:54 hurricane kernel: [724306.332797] lost page write due to I/O error on sdb1

where sdb1 was my USB backup drive partition. After digging, we finally found a thread:

http://ubuntuforums.org/showthread.php?t=494673

that talked about a similar issue. Some people saw it on NTFS, FAT32, etc – it has nothing to do with the drive format as far as we can tell.

Trick

The problem is that some drives will spin down (to save energy, we suppose), but that hoses up the filesystem and kernel for writing to it.

For us, the fix was similar to that suggested in the link above:

1) create a file in /etc/udev/rules.d called 85-usb-hd-fix.rules and add this line to it:

BUS==”scsi”, SYSFS{vendor}==”Maxtor”, RUN+=”/usr/bin/usbhdfix %k”

(where you modify the vendor to be appropriate)

2) in /usr/bin add a file: usbhdfix and put this content in it:

#!/bin/bash
# http://ubuntuforums.org/showthread.php?t=494673

echo 1 > /sys/block/$1/device/scsi_disk:*/allow_restart

3) of course, chmod +x usbhdfix as appropriate for you.

After this, our backups never failed again due to the read-only issue.

Apparently a kernel fix is coming or is already there…we didn’t chase that down.

Often during development, developers need to run multiple browsers simultaneously. They might be testing for browser compatibility, or need a plugin that only works on a older version. Whatever your situation, here are some handy options for running several versions of Firefox side-by-side.

Trick

To run multiple versions of Firefox side-by-side, launch Firefox with the following options.  You can accomplish this with a shortcut on Windows or a panel launcher on Gnome on Linux.

My Ubuntu default Firefox:

firefox --no-remote -P default %u

Other shortcuts to run other versions simultaneously…

Testing FF 3.1 with my main profile:

/home/eric/programs/firefox-3.1b1/firefox --no-remote -P default %u

Side-By-Side FF 3.1:

/home/eric/programs/firefox-3.1b1/firefox --no-remote -P ff31b1

Side-By-Side FF 2.0.0.16:

/home/eric/programs/firefox-2.0.0.16/firefox --no-remote -P ff20016

Side-By-Side FF 2 for running Firewatir (at the time, Firewatir/JSSH would not run in FF 3):

/home/eric/programs/firefox-2.0.0.16/firefox --no-remote -jssh -P firewatir

If the profile (-P) is not already there, the Firefox profile box will start.  Create a profile with the name specified by the -P option.

It’s probably best to not tell your new Firefox to be the default unless you are really sure you want it to be as it may affect your installed plugins and themes.

Enjoy!

Experiencing performance problems with Red Hat and Perl? The Perl that’s bundled with Red Hat, along with code that uses the bless/overload combination, can result in a severe system slow down. This is a known issue with Red Hat supplied Perl (Bug 379791).

Trick:

Here’s a test, some instructions on interpreting the results of the test, and suggestions on a solution to your system slow down.

First exercise Perl to determine if this known issue is, in fact, the problem you’re experiencing. To do so, run this test script:

#!/usr/bin/perl
use overload q(<) => sub {};
my %h;
for (my $i=0; $i<50000; $i++) {
$h{$i} = bless [ ] => 'main';
print STDERR '.' if $i % 1000 == 0;
}

The test script will print 50 dots on screen while using the bless operator. On a healthy system, the test should take less than 1 second to complete. With broken Red Hat Perl, the test takes much longer.

As of 8/21/08, there is a hotfix available from Red Hat for RHEL5u3 and RHEL5u2, RHEL4.5. However, users are still reporting performance issues with perl::DBI when bless/overload is utilized. For this reason, OpenLogic recommends that you obtain the latest Perl code from the Certified Library, and compile Perl yourself. The compilation of Perl is fairly straightforward, and should only take a few minutes on a server level platform. When implemented, OpenLogic Support has observed this solution result in 10X to 1000X improvement.

If you run into any problems, or have any questions about how to compile or distribute Perl, please contact OpenLogic support for instructions and help.

Relevant to: Red Hat RHEL4, RHEL5, Fedora 9, Red Hat supplied Perl version 5.8.8-10