Bash – Problem using BASH in cron (FreeBSD)

bashcronfreebsdscripting

Scenario: We have a legacy system running FreeBSD 4.7 (please, no laughing. It's being retired at the end of the year.. I just need to keep it alive and backed up until then) and I have some database dump scripts that I run daily with a cron job. I begin the script with #!/usr/local/bin/bash. The script uses the date command to put the date as part of the file name of the dump file. When I run the script manually it works as expected. However, when I put it into a cron job, it fails. I checked my error log and it's failing at the part of the script where I use backticks and the date command for the file name (I also tried $(date…) in the file name and that gave the same error. So I then tried adding /usr/local/bin/bash /path/to/script.sh in the cronjob and it still had the same error.

So my guess is that it's not switching to a bash shell when it runs. I first thought about adding echo $SHELL to my script to see, but I found that switching shells doesn't actually switch the value of the SHELL variable.

Has anyone had a similar issue with FreeBSD? Or does anyone know an alternate way I can check which shell it's using at execution? (I also tried ps >> test.txt and that didn't work in the cron either).

Best Answer

A few things occur to me while reading this.

If you are running bash echoing the value of $BASH should expand to the full path and filename of the bash executable in use.

How are you calling date in your script. Are you calling it with the full path name or as "date". The later case can result in the use of function, aliases, or whatever happens to be first in the path rather than the date program you expect.

Bash will behave differently in some cases depending on the environment. You may want to dump the environment to a file from the script and look at it running from the command-line and from cron. You may find that the PATH is different or that some other environment variable is set differently. You should be able to dump this to a file in /tmp by putting a line like "env > /tmp/environment.$$" in the script. Each time the script is run it will print out the environment to a file named environment.(pid of script)

You can set also the shell for the entire crontab to whichever shell you want by using "SHELL=/path/to/new/shell" on a line by itself.

Related Solutions

Bash – How to determine if a bash variable is empty

This will return true if a variable is unset or set to the empty string ("").

if [ -z "${VAR}" ];

Bash – the difference between double and single square brackets in bash

There are several differences. In my opinion, a few of the most important are:

[ is a builtin in Bash and many other modern shells. The builtin [ is similar to test with the additional requirement of a closing ]. The builtins [ and test imitate the functionality /bin/[ and /bin/test along with their limitations so that scripts would be backwards compatible. The original executables still exist mostly for POSIX compliance and backwards compatibility. Running the command type [ in Bash indicates that [ is interpreted as a builtin by default. (Note: which [ only looks for executables on the PATH and is equivalent to type -P [. You can execute type --help for details)
[[ is not as compatible, it won't necessarily work with whatever /bin/sh points to. So [[ is the more modern Bash / Zsh / Ksh option.
Because [[ is built into the shell and does not have legacy requirements, you don't need to worry about word splitting based on the IFS variable to mess up on variables that evaluate to a string with spaces. Therefore, you don't really need to put the variable in double quotes.

For the most part, the rest is just some nicer syntax. To see more differences, I recommend this link to an FAQ answer: What is the difference between test, [ and [[ ?. In fact, if you are serious about bash scripting, I recommend reading the entire wiki, including the FAQ, Pitfalls, and Guide. The test section from the guide section explains these differences as well, and why the author(s) think [[ is a better choice if you don't need to worry about being as portable. The main reasons are:

You don't have to worry about quoting the left-hand side of the test so that it actually gets read as a variable.
You don't have to escape less than and greater than < > with backslashes in order for them not to get evaluated as input redirection, which can really mess some stuff up by overwriting files. This again goes back to [[ being a builtin. If [ (test) is an external program the shell would have to make an exception in the way it evaluates < and > only if /bin/test is being called, which wouldn't really make sense.

Best Answer

Related Solutions

Bash – How to determine if a bash variable is empty

Bash – the difference between double and single square brackets in bash

Related Topic