tags:

views:

55

answers:

2

My ruby file is like this.

`mkdir #{HOST} -p`

It works fine by: ruby mycode.rb

But in a cron job

0 * * * * ruby ~/backup.rb >> backup.log

It will a -p folder. Why?

+2  A: 

The #1 problem that anybody runs into with cron jobs is that usually, for security reasons, cron jobs run with a minimal $PATH. So, it could be that your cron job runs with a different path than when you run the script from the shell, which would mean that it is possible that within the cron job a different mkdir comman gets called, which interprets its arguments differently.

Usually, the first filename argument stops option processing and everything that comes after that will be treated as a filename. So, since #{HOST} is a filename, everything after that will also be treated as a filename, which means that the call will be interpreted as "make two directories, one named #{HOST} and the other named -p" If you look for example at the specification of mkdir, it is simply illegal to pass an option after the filenames.

Another possibility is that for some reason #{HOST} will be empty when running under cron. Then the whole call expands to mkdir -p, which again, depending on your implementation of mkdir might be interpreted as "create one directory named -p".

It is not quite clear to me why you are passing the options and operands in the wrong order, instead of mkdir -p #{HOST}. It's also not clear to me why you use the shell at all, instead of just FileUtils.mkdir_p(HOST).

Jörg W Mittag
Thank you very much. Move `-p` forward works very well.
Cheng
+1  A: 

Another problem I've seen is the #! script line fails when /usr/bin/env is used. For instance:

#!/usr/bin/env ruby

doesn't find ruby when running under cron. You have to use

#!/usr/local/bin/ruby

or the equivalent on your platform.

Sterling Camden