Category: Shell Scripts

Little bitty shell scripts that I write that might be useful to someone.

Planet, Shell Scripts, and Binary Locations

I ran into some issues in the last week or so with getting my Planet-updating shell script invoked by CRON; it would run when I ran the script by hand, but it wouldn’t run when cPanel’s CRON spooler would try to invoke it. I was getting the following error:

Traceback (most recent call last):
File “./planet.py”, line 23, in ?
import planet
File “./planet/__init__.py”, line 23, in ?
from planet.truncate import _TruncateHTMLProcessor
File “./planet/truncate.py”, line 2, in ?
import textwrap
ImportError: No module named textwrap

After looking confused for a while, I talked to my local python guru, Stephen Granade, and he pointed something out to me: textwrap.py is a Python 2.3-era addition, so I probably had a Python environment issue. [My server has 2.2.x and 2.4.x installed. Silly cPanel.]

Armed with this knowledge, I futzed around for a while and figured out that my shell script was missing an invocation of the Python environment. I have updated it:

#!/bin/csh -f
cd /home/path/to/planet
/path/to/python/binary ./planet.py ./config.ini

Consult your system adminstrator if you don’t know /path/to/python/binary. If you’re the sysadmin and can’t find the Python binary, please ram your forehead into your desk repeatedly.

Thanks again, Stephen. I owe you a beer.

Shell Script for PlanetPlanet CRON Job

Has Sam Ruby gotten you excited about PlanetPlanet, even though you don’t know Python from Perl? Got it running, but don’t have a clue how to get CRON up and running with a shell script? Yeah, that was me yesterday. Google provided some help, eventually, but I’ll break it down a little more for you:

  1. Make sure all your file permissions are right. Half of my hell yesterday was having done all the work as root but not having CHOWN’d and CHGRP’d as appropriate.
  2. Use your shell script to change to the appopriate directory before invoking planet.py. I’d never really had to do that, as I’m still a babe in the shell-scripting woods. But if you go in, cd to the /path/to/your/planet.py, then invoke ./planet.py /path/relative/to/config.ini, you’ll be rockin’.

My shell script looks like:

#!/bin/csh -f
cd /home/path/to/planet
/path/to/python/binary ./planet.py ./config.ini

Now, I simplified things by putting config.ini and planet.py in the same folder. If you didn’t [for example, if you’re using examples/basic/config.ini just for funsies], you’d just invoke ./planet.py ./path/examples/basic/config.ini.

Thanks, Sam, for pushing me over the edge to play with PlanetPlanet. Now it’s time to get the templates like I want them so I can start using it in production. 🙂

Stripping Unwanted Referrers from Refer Database

If you use Dean Allen‘s wonderful Refer PHP script to track incoming referrers as I do, you may come across some unwanted referrers that cannot be blocked from within refer.php.

I was specifically having issues with a cached Google reference to an entry on GFMorris.com that, in a previous life, had a popup photo of my friend Samantha. Google had ‘samantha.jpg’ cached, but their incoming references to the photo are, somehow, borked. Unfortunately, Google still treats this as a valid incoming referral, probably because the photo itself hasn’t been taken down.

There must be 15 or 20 people a day who hit that image through images.google.com, and well, I was getting annoyed. So I made myself take the time to learn how to write a shell script to call a .sql script. What follows is the result of that.

.sql Script to Strip Unwanted Referrers

The .sql script is pretty straightforward: connect to the database, run a nice DELETE FROM command, then quit.

CONNECT [database];
DELETE FROM refer WHERE page = '[unwanted referrer]';
quit

Per my convention, items in [brackets] should be replaced by the end-user of the script.

If I had multiple pages that I wanted stripped, I’d just have multiple DELETE FROM commands.

Shell Script to Run the .sql Script


#!/bin/csh -f

# Log in to MySQL and run striprefer.sql.

mysql -hlocalhost -u[user] -p[password] < striprefer.sql

N.B.: This assumes that striprefer.sql and the attendant shell script—which I’ve named striprefer—are in the same directory. If they are not, you will need to reference that from the user root (e.g., ./sql-scripts/striprefer.sql).

You can’t have the shell script run the SQL commands, unfortunately. I found that out the hard way.

How I Use ./striprefer

I use a cron job to run this every hour. That’s probably overkill, but as I said, I’m using these scripts to stop an annoyance, so I’ll deal with the attendant overhead.

WordPress Backup Shell Script

For those seeking to backup their WordPress installations on a nightly basis, I have decided to publish the following shell script.

Below, any instance of a tilde [~] indicates /home/[username]/. Referencing to user root is key to this. You could change it to /home/[username]/ if you so chose.

#!/bin/csh -f

# Determine current date
setenv CURDATE date +%Y%m%d

# Backup all WP databases to compressed, dated file in home directory
mysqldump -q -e -hlocalhost -u[user] -p[pass] [database] | gzip - > ~/${CURDATE}_db-backup.sql.gz

# Backup WP files to compressed, dated file in home directory
cd ~/path/to/wp-files/
tar cf - . | gzip - > ~/${CURDATE}_files.tar.gz

Any data in [brackets] should be filled in, sans brackets.

This should sit in userroot, chmod’d to 755 to be executable.

You will get errors for all files in wp-uploads on the second TAR run for the backups. If you don’t want backups of your WP files but are more concerned about the backup of the database, remove everything from the last comment on down.

I personally get an email sent to me to verify that there were no errors in the running of the script. I also use FTP Voyager‘s scheduler to do a Move Down on the backups to a local machine. When I can get a RAID box running at home, I’ll be dumping it to that, since I trust RAID more than a single-point-of-failure HD machine. 🙂