Your lines work fine for me.

Try this... Around line 240 change this section

by adding an exit before the done like this:

You can more quickly see any error messages that way. I think perhaps you have some permissions issues. I thought I might run into that, but I didn't want to arbitrarily change everyone's permissions.

Oh and I had another idea, all that information when the script is working goes by so fast, why not create a log within the directory that the backup is in. Thanks...

My variables look something like this:
CommonRootPrefix="/kunden/homepages/00/d55555555/htdocs/"
CommonBackupPrefix="/kunden/homepages/00/d55555555/htdocs/WPBackUps"
CommonSQLBackupPrefix="/kunden/homepages/00/d55555555/htdocs/WPSQLBackUps"

What do yours look like?

I'll make the trailing slash status clearer in the next release!

Aaron:Thank you for the suggestion! It's taking a bit longer for me to digest and I wanted to clear up Joe's concern right away. I do have two minor issues with the optimization you suggest. First, people will need to edit stuff in two places. That's gonna be harder for them to do. Second, I think that this is not gonna work for shared servers. That stuff is usually restricted isn't it? Please correct me if I'm wrong and I'll investigate your method further... If it speeds it up significantly and will still work for everyone, it might be worth it.

The --remove-destination works on a file by file basis with the copy command and not at the directory level.

The Man documentation says
--remove-destination remove each existing destination file before
attempting to open it (contrast with --force)

I could use force which says
-f, --force if an existing destination file cannot be
opened, remove it and try again

But it just seemed cleaner to remove the destination.

So, the only files that will be written to (or deleted) by this script are the ones that are downloaded from wp.org. This does leave some room for clutter. If a file is removed from WP, this script will not remove it from your site. Automation is a cookie cutter business, and deciding which files were deleted from the WP release is a bit beyond its safe capablities.

Yes, the Zip will be there soon as will the SQL backups and a couple more things too I hope.

This cannot create a zip backup at this time. It is a good idea and it floated through my mind at one point. Aparently, it floated back out again when I actually got down to writing the thing...

I will put that in a later version. Thanks for the suggestion!

Here's a suggestion, especially for people who have TONS of sites. (I upgraded over 200 this afternoon). Make sure that the comments section of each user in /etc/passwd has the domain name.

usermod -c technosailor.com technosailor

Then, instead of having tons of arrays, you can just have a single one with all the domain names. I took this one step farther and queried MySQL first for all the domains from a single source, but barring that, add all the domains by hand to an array. They should be of the form example.com if that is the form used in /etc/passwd.

Now, loop through /etc/passwd with bash and use the cut command to break each line into bits using : as the separator. I use PHP as explode() works well and is simpler for me. Now you can choose the comment field and match it to the domain in the array and, using the homedir field in /etc/passwd, can easily deduce where to put your new WordPress upgrades.

Works for me but it does take a little massaging. Might be better when dealing with MANY domains. Like I said, I also prefer to use PHP CLI to handle alot of my scripting.