Short response: TZ had to be exported. Longer response below.
David Tamkin wrote,
Rik Kabel wrote,
And later, when the beeping recipe comes up:
:0c # and whatever other flags are needed
* MODE ?? ^^prod^^
* $ ^^From .* ($beep_hours):..:..
| beeper_command
Only one ^, and my version has ony one :.., but yes, this is what I do
now.
| My .forward resembles:
| "!IFS=' ' && exec /path/to/procmail -tf- MODE=prod || exit 75 #rik"
| When I try to insert TZ=EST5EDT into this, I get mixed results.
| Specifically, these
| "|IFS=' ' && TZ=EST5EDT exec /path/to/procmail -f- MODE=prod || exit 75
#rik"
| "|TZ=EST5EDT && exec /path/to/procmail -f- MODE=prod || exit 75 #rik"
| "|IFS=' ' TZ=EST5EDT && exec /path/to/procmail -f- MODE=prod || exit 75
#rik"
| have no effect, while
| "!IFS=' ' && TZ=EST5EDT /path/to/procmail -f- MODE=prod || exit 75 #rik"
| works fine.
I trust that the exclamation point is a typo and that what worked fine
actually had a pipe symbol there. Still, I'm very surprised that the first
one didn't work (the second and third are no surprise).
Yes, a typo.
| That is, the new environment does not seem to be recognized when I exec
| procmail. Of course, if this is the case I wonder if it makes sense to
| (re)define the field separator.
The definition of IFS is for use by .forward's shell in interpreting the rest
of the line, not necessarily for use by commands called in .forward, so it's
a different beast.
| What is the purpose of 'exec'ing procmail in this situation?
The purposes of execking [I'll model the gerund on "picnicking" and "panic-
king" -- or should we write "execcing" as in "siccing"?] procmail are these:
(1) If the exec happens, regardless of procmail's own outcome, "|| exit 75"
won't take effect and the exit status of .forward will be that of
procmail. ("|| exit 75" will come into play only if *exec* fails.)
Without exec, any non-zero exit status from procmail will be trapped by
"|| exit 75" and mail will be requeued (if the MTA honors the exit code).
So, in order to have an execked procmail requeue messages, the -t
option must be present, yes?
(2) If the exec happens, it replaces the shell that is running the commands
in .forward; without exec, the shell hangs around while procmail is run-
ning, using up one slot in the process table for nothing.
#2 is usually negligible.
This might be a workaround for #1 if it is a problem to set an environmental
variable along with an exec call. It might need to be on one long line, so
I'll write it that way:
"|IFS=' '&&if test -x /path/to/procmail;then TZ=EST5EDT /path/to/procmail -f-
MODE=prod;else exit 75;fi #rik"
Come to think of it, maybe exec is still usable if TZ is explicitly exported
and we can correct both #1 and #2:
"|IFS=' '&&if test -x /path/to/procmail;then TZ=EST5EDT; export TZ; exec
/path/to/procmail -f- MODE=prod;else exit 75;fi #rik"
or
"|IFS=' ';TZ=EST5EDT;export TZ;exec /path/to/procmail -f- MODE=prod||exit 75
#rik"
I ended up with something which resembles the last version you
present. Works a charm. Apparently TZ is exported by default on other
accounts of mine (on other systems), but not on Netcom, hence the
failure on Netcom.
But I think that, if you travel so much and the beep recipe is the only one
affected by the timezone, it's better to let Netcom stick with its own
TZ=PST8PDT and flip the octothorpes in and out in .procmailrc rather than
changing .forward.
It isn't the amount of travel, it's the time spent at any given
location. Were I just spending a day or two in some strange place, I
wouldn't bother resetting my watch. When I spend a week or two, I like
to make myself comfortable. A couple of other housekeeping chores get
kicked off when the month or year changes, but not too much. I will
stick with flipping .forward file and letting the octothorpes rest.
--
Rik Kabel
rik(_at_)netcom(_dot_)com