Shell Programming and Scripting

A good cron script always starts by running .profile, or some such environment file, to get the same behaviors you had interactively. Writing a .profile that is no-terminal friendly is a bit complex. You need to move all the terminal stuff to the end and test something like 'tty' to see if there is a terminal. Similarly, care needs to be taken if profile is to support both sh and ksh or bash, as sh has fewer tools and different options. e.g., no $(...) or 'set -o vi'. You might write a .profile_cron or the like and source it ( . script_path ) from .profile, so the terminal stuff can be left in .profile but all other stuff is in .profile_cron. Ditto for sh versus ksh/bash: .kshrc and .bash_profile

A few things remain different, like 'ps' options that reflect your terminal, for in cron you have no controlling terminal.

A good script, generally, has execute permissions and starts with a valid #! line as described in man execvp. Without that, it usually goes to sh as stdin.

Thanks, everyone of you for all your replies. I finally figured out how to get around this. Apparently there is sudo - su and sudo bash; these are using different profiles, and the crontab uses the sudo - su profile which is stripped down.

I placed bash in front of the path of the script in the crontab and now all my issues are gone!!

Thanks again for all your suggestions, I certainly learned a ton of new tricks!

You do not need the explicit 'bash' in front of the path of the script with a '#!<full_path_of_bash>' line 1 and execute permissions.

You actually do need bash in front of the script. There is something strange about the environment. I found out there were reports of other strange occurrences with any script not written in sh

Well, first off: you shouldn't do that. The correct syntax is:

Code:

identifier=content
export identifier

and NOT:

Code:

export identifier=content

I know, this is frequently done, which still doesn't make it correct. Notice, btw., that repeatedly exporting variables is not necessary. The oftenly seen:

Code:

x=ABC
export x
x=DEF
export x
x=GHI
export x

can be written to the same effect as:

Code:

x=ABC
export x
x=DEF
x=GHI

A variable is either exported (inherited by an eventual child process) or not, but once it is it is always exported with the current value.

Another thing is proper quoting. You write:

Code:

export PATH=$PATH:/local/mnt:/usr/sbin

and the mentioned combination of "export" and a declaration notwithstanding: what will happen if $PATH" contains white space? To protect your script from breaking in such a case always protect your variables:

Code:

PATH="${PATH}:/local/mnt:/usr/sbin"

A last thing: scripts should ALWAYS be written in a way so that they are indifferent to the place where they are started from. This means, first and foremost, you should always use absolute pathes to address files:

WRONG:

Code:

inputfile="input.file"
outputfile="output.file"

grep 'something' "$inputfile" | while read line ; do
     do_something "$line"
done > "$outputfile"

This will work or not, depending on which directory the script was started from. Inserting a "cd /some/where" in the first line might help but is bad style (and in the long run dangerous).

CORRECT:

Code:

workdir="/some/where"
inputfile="${workdir}/input.file"
outputfile="${workdir}output.file"

grep 'something' "$inputfile" | while read line ; do
     do_something "$line"
done > "$outputfile"

The variables "$inputfile" and "$outputfile" contain now absolute pathes and the script will work regardless from where it is called from.

One very last thing: DGPickett is correct! If your first line looks like:

Code:

#! /path/to/your/bash

Then the executable "/path/to/your/bash" is used to run the script, not any other executable at all. Even if there is another (version of) bash installed somewhere (like in "/usr/bin" or whereever) it will not be used, but exactly the specified (executable) file. This is the better solution to use because you specify inside the script by which executable it should be run, not outside of it (where it could be changed without changing the script itself)!

I hope this helps.

bakunin

Hi bakunin,
Actually, the POSIX Standards have required conforming shells to support export commands with the SYNOPSIS forms:

Code:

export variable[=word]
      and
export -p

since 1992.

But, of course, if you're working on a project that is still using a pure Bourne shell, you'd still need to avoid assigning a value to a variable in an export command.

Oops. ~blushes~

I have to admit that i do not (any more). I just learned that once and never bothered to change my habits. Thanks for the correction.

bakunin