I'm using (as I have been for decades) calendar, called from root's crontab at 0200 every morning. Problem is, it's running, but the emails go to root's email as bounced messages.

Seems root is trying to send to jim@JinxsSlack.local, which is the system name. root's line in crontab reads:

0 2 * * /usr/bin/calendar -a

Is there a specific way in calendar (running from root's crontab) that I can tell it to use jim, not jim@...... ? Or perhaps as an option in crontab? The man page for crontab is for the command only. There is no crontab(5) for the crontab file, itself (nor is there one in any other man sections---I did a "ls crontab **/*" and the only place it was found was crontab(1).

Looks like I need to copy yet another file from my old Mint system. Hell, I had to copy all of the calendar stuff from there because slackware couldn't fine it---no idea where it is on slackware or why it isn't in a "normal" path (nor are the man pages for it).

So does anyone know how to make calendar's entry in root's crontab send to me as jim only, as again, opposed to jim@blaBlahBlah?

Thanks,
--jim

That calendar tool is not part of Slackware. Are you trying this on a non-Slackware distribution?
If the cron runs as root, any standard and error output from the cron job is emailed to root. If you defined an alias for root you would find it in /etc/mail/aliases .

Since calendar is not in Slackware, I do not know what it does. I hope you can tell me. Will it send emails all by itself? And have you configured "jim" as the recipient of those emails?

You did see that I had to take all of the stuff for calendar(1) from my
old Mint system, right? As for Slackware not having it, that is NOT
normal. calendar(1) is a standard part of any/all Unix variants, period.
You have a program called calendar, and a file in either your home
directory or a directory under it (depending on how calendar(1) is
configured. Either way, you can run it as calendar -f [calendarfile].
The calendar file looks like this:

3Jan<TAB>I have something I need to do on this day, possibly at a certain time

If you run calendar(1) yourself, you'll have that show up on your screen
on 2Jan and 3Jan (weekends are special). If root runs it from crontab,
either as "calendar-" for most versions, or "calendar -a" for others, it
goes through every users' calendar file, and using the same scheduling
rules, sends them an email (local on the system) if they have anything
current. I've never heard of any Unix, including any Linux, that doesn't
have calendar. That's just not normal. It's far too useful to not have.
That's why I "borrowed" it from my ancient Mint system that's on an even
more ancient laptop.

Btw, running it yourself and seeing it on screen, or having root send you
an email as a result of having calendar - (or -a on some systems), you
get an email, usually with the subject of "calendar output" that has
that same line as typed above, and again, that's the day before and
the day of, and weekends are treated special (meaning I don't remember,
offhand, which days, from Friday to Monday, get what on which days).

As a two-time cancer survivor, I have medical appointments all the time,
meds and injections to take that must be done on schedule, personal
stuff, etc., that it makes it trivial to keep track of. I also have
a backup in an Android app called MedHelper (free and worth its weight
in gold if you're in a situation even remotely like mine). My calendar
file is always updated. MedHelper is almost always updated, unless I
forget (and chemobrain can easily take care of making me forget stuff).

So back to the question: Does anyone know how to either configure
calendar(1) or root's crontab to send the emails directly to me as
"jim" and not to "jim@JinxsSlack.local" when calendar (run every
morning at 0200) tells it to send an email to me with the line (or
lines) current entries that it finds?

Oh, and just to be clear, contrary to what some people on the 'net
seem to think, no, calendar is not in any way related to cal (even
search engines get that all fragged up). :-)

Thanks,
--jim [this line is actually indented by three spaces, and
the line below it doesn't exist and is not really there]

Btw, I said it's a standard on (well, ok, all but Slackware,
apparently) Unix variants, I do NOT know about UNIX(tm), also
known,before the Divestiture of 1984, as AT&T System V. And I
have no idea who owns it this week (it used to change hands
routinely ... don't know or care if it still does).

Later

This calendar tool looks like the BSD calendar.

(Incidentally, there is a Slackbuild https://slackbuilds.org/repository/1.../bsdmainutils/ that adds "printerbanner", "calendar", "bsd-from", "lorder", and "bsd-write" to Slackware 15.0.)

The command "calendar -a" means "Process the calendar files of all users and mail the results to them. This requires superuser privileges." So to Windu's point, yes, it does appear the command will send emails itself. Looking in the source, at least one version of BSD calendar does this by:
and passes the recipient as a To message header consisting of just the recipient's pw_user field from the password file.

This means, for diagnostic purposes, it looks possible to take calendar completely out of the picture. What happens when you issue the following command lines (as root)?

On my Slackware64 15.0 system, syslog shows that the address is translated by postfix from simple "jim" to "jim@(domainname)". If I have a user "jim" then the email gets delivered properly.

If that does not work on your system, then the email configuration needs a closer look.

Before I even got to the above, I ran a little test with the new BSDmainutils calendar (still in /usr/bin/calendar). As root, I ran

(18:30) # /usr/bin/calendar -a

And it sent the mail to me as it's supposed to. Unless I'm horribly missing something, that tells me that whatever the issue is,
it's a cron issue, and (most likely) has nothing to do with calendar. What's even more strange is that when, as root,I send myself
an email from the command line using mailx, it both creates /root/dead.letter AND sends the email to me normally.

I'm 99% sure I'm using Postfix. Doesn't matter much to me, both it and sendmail since they got rid of /etc/sendmail.cf (which was
so incredibly easy for me to work with) and switched to that new thing that I've never been able to work with. Anyways, that's just
a quick OT comment about my email setup.

So how would mail work differently under the cron environment than it does from a shell (zsh, which is sh plus a LOT of extra power)?

Thanks,
--jim

The Slackware default is Dillon's cron: man crond. Other cron daemons are available at slackbuilds.org.

To have the cron daemon send an email use the -m option. If the option is not explicitly used then there is no email unless the command itself is designed to send emails or there is an error.

The default with Slackware cron logging is /var/log/cron. That log should provide some clues. If not, check /etc/default/crond and change CROND_OPTS="-l debug".

Commonly many people find that running a command succeeds in a console or terminal window and then fails in a cron job. A common reason for cron jobs failing or acting unexpectedly is unlike the at daemon, cron does not inherit a full user environment. One way to ensure everything runs as expected is using a shell script wrapper and declare variables such as $PATH inside the script. Also always use full paths in cron jobs. That probably is not the problem here though.

To forward all of root's mail to a non-root user, edit /etc/[mail/]aliases:

In my aliases file I use short hostnames (hostname -s) defined in my /etc/hosts file.

Then as root run the newaliases command.

When I tinker with a new system I always check that mail is functional:

echo "This is a test" | mail -s Testing root@localhost

I then use a mail client or the mail command as my normal user to verify the mail was forwarded as defined in the aliases file.

I'm still using sendmail rather than postfix. One way or another an SMTP server is needed. Pat supports sendmail in the /extra branch of the repository.

I have done my share of using and testing other distros. The calendar command is not part of a default install in many distros. As already noted, the command is part of the bsdmainutils package, which is not part of the parent Slackware repository but found in slackbuilds.org. Regardless of the distro that package needs to be installed.

I don't know if in the original post this is a typo, but the command is missing an asterisk.

0 2 * * * /usr/bin/calendar -a

I hope that helps.

2 members found this post helpful.

The Slackware default is Dillon's cron: man crond. Other cron daemons are available at slackbuilds.org.

To have the cron daemon send an email use the -m option. If the option is not explicitly used then there is no email unless the command itself is designed to send emails or there is an error.

The default with Slackware cron logging is /var/log/cron. That log should provide some clues. If not, check /etc/default/crond and change CROND_OPTS="-l debug".

Commonly many people find that running a command succeeds in a console or terminal window and then fails in a cron job. A common reason for cron jobs failing or acting unexpectedly is unlike the at daemon, cron does not inherit a full user environment. One way to ensure everything runs as expected is using a shell script wrapper and declare variables such as $PATH inside the script. Also always use full paths in cron jobs. That probably is not the problem here though.

To forward all of root's mail to a non-root user, edit /etc/[mail/]aliases:

In my aliases file I use short hostnames (hostname -s) defined in my /etc/hosts file.

Then as root run the newaliases command.

When I tinker with a new system I always check that mail is functional:

echo "This is a test" | mail -s Testing root@localhost

I then use a mail client or the mail command as my normal user to verify the mail was forwarded as defined in the aliases file.

I'm still using sendmail rather than postfix. One way or another an SMTP server is needed. Pat supports sendmail in the /extra branch of the repository.

I have done my share of using and testing other distros. The calendar command is not part of a default install in many distros. As already noted, the command is part of the bsdmainutils package, which is not part of the parent Slackware repository but found in slackbuilds.org. Regardless of the distro that package needs to be installed.

I don't know if in the original post this is a typo, but the command is missing an asterisk.

0 2 * * * /usr/bin/calendar -a

I hope that helps.

2 members found this post helpful.

Try thisdirect the cron job output to the specified email address without including the domain part (jim@JinxsSlack.local). The MAILTO variable affects all cron jobs in the crontab file.

That might work if calendar -a wrote to stdout and left the mailing of the output to cron. Unfortunately it does not. Instead, calendar -a internally composes and sends multiple emails, addressing one to each local user who has a calendar.

I might be mistaken but I don't think variables such as SHELL=, PATH=, and MAILTO= are recognized by Dillon's cron.

I m wrong, @lostintime and @metaed are right. sorry.

Not wrong really, the variables are supported in most of the other cron packages. I discovered this anomaly some years ago when working as an admin. When I migrated some of the job cron jobs to my home network none of those variables functioned.

Apparently, that's been fixed. I fixed a typo that someone else pointed out (one missing *) and changed my calendar entry for a minute later.
It ran just fine, even though crond was not launched with the -m option, only as "/usr/sbin/crond -l notice" (according to ps) -ax).
It;s working fine now. And thanks for pointing out where crond's log is. I found a message that it failed to parse the line for calendar
every time it tried. That reminded me about the post here pointing out that missing *. I fixed that and that was THE problem.

So thanks everyone! I'm marking this as solved as soon as I send this.