Iraniblog

I remember reading about the new features of Firefox 3 before it came out many moons ago and how the new bookmarking features would blow our minds. Well, blow my mind, it did. The upgrade actually did such a great job, I forgot about one of the features they really stressed before the release: keywords. The claim was that you could map your bookmarks to your own preset strings and then call up the bookmarks by entering the string. I thought this was an interesting idea, but seemed a bit much. Anyways, when Firefox 3 actually did come out, they included this great feature where the link bar would do a full text search against your link history. This feature made bookmarking things almost useless, since it was probably quicker — and more natural — to type in some text as you remembered it into the link bar, and what you wanted would usually just come up. Pretty amazing stuff.

So now, why did I bring up the keywords if everything’s so great in FF3-land? because they actually add even more utility to this setup. I setup keywords for the things I least want to have to go through a menu for (and for which I probably shouldn’t have to use my mouse): a link to my repository, the company wiki, and our bug reporting tool. I added little keywords for those three things, and really like how simple and easy they are to reach now. This is one of those things that I’m sure you knew about, but it’s so simple to setup, and is actually a great little thing to have in place for those web tools you keep going to over and over. Especially with the advent of web tools taking the place of where real GUIs used to live.

For the sake of clarity, here’s one example of how I use the keywords. I have my bug tracking software bookmark set to the keyword ‘bugs’. All I do is press ‘ctrl-l’ type in ‘bugs’ and it shoots to my bug tracker.

I wrote a Python script that I want to run every five minutes through a crontab. The script ran fine and linked with my local libraries until I ran it through the crontab and it couldn’t find my local libraries. After a bit of thought, I realized that the crontab was not running through the same shell environment as I expected it to. Apparently the shell is set in /etc/crontab file and there it was set to bash. That in turn was calling the wrong version of Python, and that was why my local Python scripts weren’t being found.

There are four different ways around this:
1) Modify /etc/crontab to hit the right shell; in my case (first line modified):
/etc/crontab

SHELL=/bin/tcsh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

crontab -e

*/5 * * * * python /my/script.py

2) Add the shell value to the top of the custom crontab (crontab -e); in my case:

SHELL=/bin/tcsh

*/5 * * * * python /my/script.py

3) Run the actual command through the tcsh as so:

*/5 * * * * tcsh -c "python /my/script.py"

4) Directly request the right version of Python:

*/5 * * * * /tools/bin/python /my/script.py