fixed - though I am a little embarrassed to report what the issue was but am obliged in case it benefits someone else in the same situation.
I also needed to preceed the path to my script file with sh in the crontab: 0 2 * * * /windows/E/admin/backup-email.sh (won't work) 0 2 * * * sh /windows/E/admin/backup-email.sh (is good) thanks for the other suggestions. the use of windows in many of the directory paths on this machine is simply an inheritance from a previous linux install and continuation of that nomenclature while i came to terms with doing things differently in linux. the various partitions in use here are not NTFS (fat32, only because other windows machines may use them) and fstab isn't making them noexec. i've defined Tar in addition to BackupFileName so can use both $Tar and $BackupFileName in the script. main challenge was the exposure to vi - while I could use webmin to set the whole thing up, I actually only did so as a test to force the running of the job "right now". command line and vi is actually much easier (once you actually know enough commands to use vi) after all the comments I have read about how challenging but useful vi is, I totally agree. given you are forced to use it when doing "crontab -e" I reckon many newishbies will run from cron never to utilise it's potential. the majority of the time getting this all to work was actually with learning enough vi commands to get 3 lines in my cron table. it was worth the effort, and i'm tempted to say that i actually like vi and will use it again as soon as i have the chance (but will keep that comment to myself...) anyway thanks again for the help getting this working. actually lets me take care of (nearly) all my backing up requirements. Roger Steve Holdoway wrote: > On Fri, 09 Mar 2007 15:10:32 +1300 > Roger Searle <[EMAIL PROTECTED]> wrote: > > >> so now that I have my backup script files ready and functional from >> either the command line or mouse click, I want cron running them, so am >> doing "crontab -e" - i understand the format of crontab. i restart the >> cron daemon or ensure that at least 2 minutes will pass before schedule >> runs. however when the scheduled time has passed the expected file will >> not have been created. i will have mail in var/spool/mail/roger saying: >> >> >> /bin/sh: /windows/E/admin/backup-test.sh: /bin/bash: bad interpreter: >> Permission denied >> >> alternatively i can use webmin to view the cron jobs and make it run >> "now" - the same error is returned. >> this will happen regardless of whether the cron job is run as roger or >> as root. >> >> plenty of references to this error in google but nothing that seems >> helpful - particularly since it will run from the command line and the >> suggestions are usually to do with permissions. root and users both >> have execute permission to the file. >> >> any suggestions anyone? >> >> Cheers, >> Roger >> > > almost all errors in cron jobs are caused by the almost total lack of an > environment that they're runnin in. Most painfully, the PATH isn't set in any > useful way, which means that you either have to set it up at the start of > your script, or you need to specify the absolute path of all commands. > > For some reason - don't ask me why - I use the latter. For example, my > generic backup script has a block of declarations like > > Tar="/bin/tar --create --verbose --ignore-failed-read" > Scp="/usr/bin/scp -P 2222 -q" > Rm="/bin/rm" > Find="/usr/bin/find" > Gzip="/bin/gzip" > MySQLDump="/usr/local/mysql/bin/mysqldump --all-databases --add-drop-table > --flush-logs --extended-insert --create-options --disable-keys > --single-transaction --quick" > PGDumpAll="/usr/local/pgsql/bin/pg_dumpall" > Mount="/bin/mount" > Umount="/bin/umount" > MkDir="/bin/mkdir" > > > > and I usr $Tar tather than tar to run the command. > > > Steve > >
