chip@vector.UUCP (Chip Rosenthal) (02/12/89)
Chapter three of the continuing saga...
In part one, I mused about ripping out the SCO XENIX mail system.
In part two, I did so and replaced it with "free" software (Elm,smail,deliver)
In part three, we look at a strange problem introduced by the above...
One thing I did was write a quick /bin/mail which is similar to the
svbinmail.c distributed with smail 2.5, but simpler. The idea is that
"/bin/mail" immediately execs either "/bin/smail" or "/usr/bin/mail", as
appropriate. Although everything could go through "/usr/bin/mail", this
approach gets stuff directly into smail and saves a couple of execs.
Here is where things get interesting. All of a sudden, the mail messages
from several of my cron tasks were getting messed up. Sometimes part of
the message would be interspersed with the mail header, sometimes not.
I spent a couple of days trying to figure out why certain mail messages
failed and others worked, and trying to come up with a repeatable way of
causing the failure.
For example, when maps were unbundled, I would get something like:
From news Sun Feb 12 00:31:43 1989
Received: by vector.UUCP (smail2.5)
id AA07128; 12 Feb 89 00:31:40 CST (Sun)
shar: extracting u.usa.ny.2
Message-Id: <8902120031.AA07128@vector.UUCP>
Date: 12 Feb 89 00:31:40 CST (Sun)
From: news@vector.UUCP (USENET News Administrator)
To: chip@vector.UUCP
*************************************************
Cron: The previous message is the standard output
and standard error of one of your cron commands.
Note that the "shar" message is stuffed in the header, but the "cron"
message is in the body.
Suddenly it dawned on me. This problem only happens when the message
starts off with a program diagnostic. You know:
progname: some diagnostic message
Smail is treating these diagnostics as mail headers. I haven't fixed this
yet. I see a couple of approaches:
(1) Throw away /bin/mail and let cron work through SCO's /usr/bin/mail.
A giant step backwards.
(2) Force a blank line or a mail header at the top output from my "cron"
tasks. Ugly. This means mail messages even when there is output.
(3) Handle the output directly inside the cron task rather than letting cron
do it. Kind of a pain in the neck.
(4) Drop the XENIX cron, switch to one of the free ones, and fix it there.
I prefer #4, I think. But #1 would be the easiest.
--
Chip Rosenthal chip@vector.UUCP | Choke me in the shallow water
Dallas Semiconductor 214-450-5337 | before I get too deep.daveh@marob.MASA.COM (Dave Hammond) (02/13/89)
In article <705@vector.UUCP> chip@vector.UUCP (Chip Rosenthal) writes: >Smail is treating these diagnostics as mail headers. I haven't fixed this >yet. I see a couple of approaches: > >(1) Throw away /bin/mail and let cron work through SCO's /usr/bin/mail. > A giant step backwards. > >(2) Force a blank line or a mail header at the top output from my "cron" > tasks. Ugly. This means mail messages even when there is output. > >(3) Handle the output directly inside the cron task rather than letting cron > do it. Kind of a pain in the neck. Not such a pain, in the face of (1) returning to the old mailer, or (4) replacing cron. I'd redirect fd 2 to a log file, then mail the log file to root (or whoever). I don't know particulars of your cron task, but if standard output is likewise undesireable, a quick fix is: cron_task 2>&1 |mail root For situations like this it would be handy to be able to redirect a particular file descriptor to a pipeline, something on the order of: cron_task |<2 mail root -- Dave Hammond daveh@marob.masa.com
chip@ateng.ateng.com (Chip Salzenberg) (02/15/89)
According to chip@vector.UUCP (Chip Rosenthal): >Chapter three of the continuing saga... >One thing I did was write a quick /bin/mail which is similar to the >svbinmail.c distributed with smail 2.5, but simpler. The idea is that >"/bin/mail" immediately execs either "/bin/smail" or "/usr/bin/mail", as >appropriate. Smail will accept a header at the front of a message, whereas /usr/bin/mail will not, ever. So if you invoke Smail directly, you'd better be sure the beginning of the message doesn't look like a mail header. >I see a couple of approaches: >(1) Throw away /bin/mail and let cron work through SCO's /usr/bin/mail. > A giant step backwards. How is this a giant step backwards? You can't change the behavior of a program as commonly used as /usr/bin/mail without expecting breakage. I say: It's not great, but it's good enough. Leave /usr/bin/mail. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."