A UNIX process has not one but *two* outputs by default: <stdout> and <stderr>

To capture them in a file you have to use two output redirections accordingly:

command 1> /some/file or
command > /some/file

will only redirect the file descriptor 1 (which is <stdout>). <stderr> will not be redirected and hence go to the default I/O device, in this case the screen of the terminal. To redirect the output on <stderr> too, issue:

command 1> /some/logfile 2>/some/errorfile

This will send the output to <stdout> to /some/logfile and the output to <stderr> to /some/errorfile. The same is true for cron (which is just another means to start processes) jobs. Probably you just haven't redirected the <stderr> output channel.

BEWARE:

Usually redirection is done in this casual way:

command >/path/to/logfile 2>&1

"2>&1" means: redirect file descriptor 2 ( = <stderr>) to where file descriptor 1 (<stdout>) points right now. The problem is, that these two file descriptors are still not the same and redirecting FD1 to somewhere else doesn't mean FD 2 will change too. A common pitfall is:

command 2>&1 >/path/to/logfile

which will first redirect FD 2 to where FD 1 points (perhaps the screen), then redirect FD 1 to a file. Most likely the intention was not this, but to redirect both to the same file, which would be achieved by the first example. To avoid any ambiguities better write it down this way, which doesn't depend on the order of the parts:

command 1>/path/to/logfile 2>/path/to/logfile

Hope this helps.

bakunin