Rik Kabel wrote,
| My actual timezone varies as I travel, and I wish to have my mail forwarded
| based on the time of day.
If you travel and need to have TZ match the timezone of your current
location, that's a pain no matter what.
| I don't want to be beeped at 3 in the morning because I am a few zones
| away from the server and my recipe says to beep until midnight,
| otherwise just file it.
| I have no trouble accessing the server and changing a parameter or file
| setting, either in .procmailrc or in .forward.
If you don't mind changing your .procmailrc when you change time zones, then
you could use a variable assigned earlier in the rcfile. Let's say that you
want to be beeped from 8 AM until midnight your local time; for locations in
the contiguous US, we can have this:
# Set to Netcom time during beeping hours; comment or uncomment as needed:
# beep_hours="0[89]|[12]." # for PT or Arizona spring/summer
# beep_hours="0[789]|1.|2[012]" # for MT except Arizona spring/summer
# beep_hours="0[6-9]|1.|2[01]" # for CT or Indiana spring/summer
beep_hours="0[5-9]|1.|20" # for ET except Indiana spring/summer
[Six counties in southwestern Indiana and five in northwestern Indiana are
in the Central Zone and observe DST the usual way; those Indiana exceptions
are for the other eighty-one counties, which remain on EST all year.]
And later, when the beeping recipe comes up:
:0c # and whatever other flags are needed
* MODE ?? ^^prod^^
* $ ^^From .* ($beep_hours):..:..
| beeper_command
When you're three hours ahead of Netcom, beeps occur from 5 AM to 9 PM Netcom
time, or 8 AM to midnight where you actually are. The first condition is so
that you are beeped only if mail went through .forward and not if you repro-
cess mail through your .procmailrc without -f- and it originally arrived
during what would be beeping hours for your current timezone. (I got messed
up by something like that once.)
| 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).
| 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).
(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"
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.