cron shell scripts Summary

Dear Bill R. Williams and Mr. Aaron Lineberger;

Thank you both for your swift replies.

I am fully aware of the Best Practice for shell scripts whereby the 
first line contains the she-bang shell definition e..g

#!<shell>

However, I had a very nasty experience last time whereby a KORN shell 
script I wrote (with the proper #!/usr/bin/ksh in the very first line) 
worked very well on the command line but completely failed in CRON.

However, when I added the /usr/bin/ksh <korn shell script> to the cron 
entry, it worked just fine.

This lead me to the incorrect conclusion that the CRON daemon simply 
does the equivalent of

sh <shell script>

which does NOT interpret the first she-bang (#!<shell>) line for 
executing shell scripts.

Mr. Bill R. Williams correctly pointed out that PERL scripts runs just 
fine and that alone should have told me that my conclusion was incorrect.

Ah well......it was a dum conclusion and I am sorry to have wasted your 
time!

Thanks once again for both of your replies!

Warmest Regards
Steven Sim

Bill R. Williams wrote:

>Hi Steven Sim,
>
>  
>
>>Am I mistaken??
>>    
>>
>Well... just a bit somewhere along the line. :-)
>
>Remember: cron can run a binary.  Or a perl script.
>Or pretty much whatever command you can enter when 'sh' is your shell;
>including some other shell.
>
>If you start your script with the standard '#!/PATH/SHELL' -- such as
>'#!/usr/bin/ksh' -- the script should be run with ksh.
>I have perl scripts in my (Solaris9) crontabs and they run under the
>indicated '#!/usr/bin/perl' interpreter.
>
>The things I have observed (first hand and/or from discussion lists)
>which seem to be the "gotchas" in a cron job are:
>
>*  The script or program runs fine on the command line, but when used
>   as a cron job it fails.  Usually a "can't find ..." type error.
>   The environment under cron is not the same as what the user has in
>   interactive mode especially the PATH.  (Note: 'at' is not the same
>   as cron because 'at' will snarf up the current environment when it
>   is invoked and feed it to the at-ed job.  Except for STDIN, STDOUT,
>   STDERR from/to the TTY it's almost the same as interactive.  Sorta.)
>
>*  A script is created without the "#!..." which uses ksh or bash
>   constructs because the user has whichever one as their shell.  They
>   schedule it into cron which will use its default interpreter: sh
>   Those ksh or bash enhancements will fail under plain ol' Bourne sh.
>
>
>Having said all that which you probably already knew...
>I see nothing wrong with specifying the interpreter (sh, bash, ksh)
>with its script.  Of course my eyes ain't what they used to be. :-)
>  
>




Fujitsu Asia Pte. Ltd.
_____________________________________________________

This e-mail is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. 

Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers