People often ask in comp.lang.tcl about problems they're having with their Tcl-coded cron applications. Almost without exception, the problems have nothing to do with cron (in the usual sense programmers mean that). However, until one of us can locate a good online introduction to cron and its maladies, we'll record here the things a newcomer should know.
First, of course, is to decompose the problem. If you have a cron application that's misbehaving, how does the same program act outside cron? Answering that question typically is the most valuable first step in diagnosis.
effective user
env vars
Remember that cron provides to the application a SEVERELY limited environment. You might, for fun's sake, add something like:
0 8 * * * /bin/env
to your crontab . This should , in most cases, result in you receiving an email with the environment variables that cron sets for the average app.
Why should this matter? Because many apps depend on things like $HOME, $PATH, $DISPLAY, $LD_LIBRARY_PATH, $TCLLIB, or other environment variables none of which are set by cron. In fact, I have seen people do things like invoke /etc/profile (or some similar file for other shells) as well as a specific home/.profile type file within a wrapper shell before running their c code.
#!-non-portabilities
Trying to run X apps from within cron
#!-32 character limit (is it 32? for which Unixes?) (what about when symlinked? Where on the Web is this documented?
At least one place that #! is documented, on Solaris, is exec(2). What the doc discusses is general terms under errors returned by exec (which is ultimately what is being invoked to get to the #! ...)
ENAMETOOLONG
The length of the file or path argument exceeds PATH_MAX,
or the length of a file or path component exceeds
{NAME_MAX} while {_POSIX_NO_TRUNC} is in effect.(along with quite a few other errors). Of course, it depends on what headers, etc. are included what the value of these are. However, frankly, this value appears to be 1024 on Solaris. On other systems, the values will likely be different - and in fact, there may be limits on #! other than this , depending on the OS.
[Point to a description (in the FAQ?) of the telnet bug in case TERM is undefined, unrecognized, ...]