Executing script through cron

[shrady]

I have a script that works fine and sends the required output via mail when i run it manually; however, when I put it in cron, it gets executed at the said time but does not run fine. I guess, it is an issue with the shell that we define at the first line in the script.
I had faced a similar issue on one server. When i added "/usr/bin/sh How do I eliminate this issue in the script?

[Sagar Sirdesai]

Hi
Try adding the below line to your script and see if it works..
#!/usr/bin/sh to your script.

Sagar

[shrady]

Thanks Sagar, please see the second paragraph of the query:
"I had faced a similar issue on one server. When i added "/usr/bin/sh
I have tried this :(

[Sagar Sirdesai · Accepted solution]

Hi

My advice is to add the she-bang #!/usr/sbin/sh to your script...

Please ignore if it is already tried...

[likid0]

This normally has to do with the shell enviroment, and missing paths to commands(that you have in your PATH variable via .profile) when cron executes the script.

Try and give absolute paths to commands not in standard bin directories

[James R. Ferguson]

Hi:

If you examine the 'crontask(1)' manpages you will see that the environment that 'cron' provides is very sparse. Specifically the following are set:

HOME=userâ s-home-directory
LOGNAME=userâ s-login-id
PATH=/usr/bin:/usr/sbin:.
SHELL=/usr/bin/sh

This means that environmental variables that you have specified in your login profile don't exist either, by default, since the login profile is not read.

If you profile contains the necessary environmental variables, you can "source" (read) that as the first step of your crontask. A common problem with using the profile, however, is that the standand HP-UX '${HOME}/.profile' contains terminal interactive commands like 'stty' and 'tset'. Since a cron'ed task isn't interactive (associated with a terminal) unless you condition-out this profile code, you get messages of "Not a typewritter" when you cron your task.

A very clean way to handle environmental variables that you want to use in scripts, is to create a separate file of them that you can be "sourced" (read) whenever necessary. By example, you could do:

# cat /home/shrady/env
#!/usr/bin/sh
export PATH=$PATH:/home/shrady/scripts
export SHLIB_PATH=/home/shrady/1981
export TZ=UTC

The interpreter line (the "she-bang") is optional for files that will be sourced. My personal preference is to declare it as a form of documentation at-first-glance.

To use this, do:

. /home/shrady/env

...Note the dot character (".") followed by a space (blank) followed the absolute path of the file you want to read "into" your script. This is what is called "sourcing" a file.

# . /home/shrady/env; /home/shrady/scripts/mything

...or in a crontab:

1 * * * * ./home/shrady/env;/home/shrady/scripts/mything

The file of your variables can also be sourced at the end of your login profile too. Thus, only ONE copy of variables needs to be maintained.

Regards!

...JRF...

[Dennis Handly]

>it is an issue with the shell that we define at the first line in the script.

It shouldn't be. If you use #! shell, then sh will execute that shell.

>When I added "/usr/bin/sh
You shouldn't have to do that since cron is going to use sh anyway. Unless your script isn't executable?

[shrady]

Thanks James! Issue solved after setting proper env