Change Details

I tested each of the following crontab entries in isolation: # should both log and send email * * * * * date # should only send email, but won't show up in log * * * * * -q date # should not send email * * * * * -n date # should not send email or log * * * * * -n -q date # should send email because of ping failure * * * * * -n -q ping -c 1 5.5.5.5 I also tested to ensure the command options work using the /etc/crontab format which requires user to be specified. Also, I tested the empty command entry, e.g.: * * * * * This will log but never send an email. However, because of the way the parsing works, an empty command is not supported in conjunction with command options. So: * * * * * -q will not parse as valid crontab syntax. I suspect this is the same behaviour as OpenBSD crontab, and frankly makes sense - since an empty command entry only purpose is to provide a signal in the cron logs.

I tested each of the following crontab entries in isolation: ``` # should both log and send email * * * * * date # should only send email, but won't show up in log * * * * * -q date # should not send email * * * * * -n date # should not send email or log * * * * * -n -q date # should send email because of ping failure * * * * * -n -q ping -c 1 5.5.5.5 ``` I also tested to ensure the command options work using the /etc/crontab format which requires user to be specified. Also, I tested the empty command entry, e.g.: ``` * * * * * ``` This will log but never send an email. However, because of the way the parsing works, an empty command is not supported in conjunction with command options. So: ``` * * * * * -q ``` will not parse as valid crontab syntax. I suspect this is the same behaviour as OpenBSD crontab, and frankly makes sense - since an empty command entry only purpose is to provide a signal in the cron logs.

I tested each of the following crontab entries in isolation: ``` # should both log and send email * * * * * date # should only send email, but won't show up in log * * * * * -q date # should not send email * * * * * -n date # should not send email or log * * * * * -n -q date # should send email because of ping failure * * * * * -n -q ping -c 1 5.5.5.5 ``` I also tested to ensure the command options work using the /etc/crontab format which requires user to be specified. Also, I tested the empty command entry, e.g.: ``` * * * * * ``` This will log but never send an email. However, because of the way the parsing works, an empty command is not supported in conjunction with command options. So: ``` * * * * * -q ``` will not parse as valid crontab syntax. I suspect this is the same behaviour as OpenBSD crontab, and frankly makes sense - since an empty command entry only purpose is to provide a signal in the cron logs.