Why does this shell script fail in bash, but the commands work in SSH?

Question

What I'm trying to write is a shell script that will back up a website and all the MySQL DBs that support it. I found examples all over the 'net, but when I run the script in bash in a jailed SSH session, it fails. If I type the commands straight into the SSH session, they work fine.

#!/bin/sh

DB1="first_db"
THEDATE=$(date +"%Y-%m-%d")
THEUSER=user
THEDBPW=password

mysqldump -u $THEDBUSER -p$THEDBPW $DB1 > dbbackup_$DB1_$THEDATE.sql

tar -czf sitebackup_website_$THEDATE.tar /home/website/public_html
gzip sitebackup_website_$THEDATE.tar

This script lives on the web server, so for testing purposes, I SSH into the server, cd into the directory, and run bash backup.sh. mysqldump isn't connecting, seeming to fail to pass the password in (it returns an error reporting 'using password: NO'). Then the tar command fails, reporting that it can't stat /home/website/public_html with a 'no such file or directory'. tar then reports it is exiting with error status due to previous errors.

What am I missing here?

Answer 1

Check the script for Windows line endings by logging in on the server and running

cat -v /path/to/script

If the line ends with ^M, that is the problem.

You can fix a file with broken line endings by running

dos2unix /path/to/script

If dos2unix doesn't exist on the server, you can instead use sed, like this:

sed -i 's/\r$//' /path/to/script

Answer 2

You have assigned the username to variable THEUSER, but your mysqldump command is using the variable THEDBUSER.

Answer 3

tardir=$PWD ; cd /home/website/public_html && 
    tar -czf "$tardir"/sitebackup_complete-office_"$THEDATE.tar"

or just:

tar -C/home/website/public_html -czf \
    sitebackup_complete-office_"$THEDATE.tar"

In general many tars will fail to work at all with absolute paths unless explicitly instructed to do so.

By default, GNU tar drops a leading / on input or output,and complains about file names containing a .. component. This option turns off this behavior.

It's entirely possible that ssh's commands are resolving paths beforehand depending on command delivery and quoting. The same is relevant to the expansion of the variables in your pathnames.

Answer 4

If I understand you description of the problem correctly, the key difference seems to be the jailed SSH session - processes running inside the jailed session cannot see outside of their jail directory (often their home). That's why you don't experience problems in non-jailed session. Yo might also have a look at the wikipedia Jail entry for more details.