Chris Oxenreider asked,
| In short, any of the three OSs can be the recipiant of an e-mail message
| and process via the .forward file. Since I don't have privies to put
| procmail into /usr/local/bin i have it in my $HOME/bin. The problem is
| exec(ing) the appropriate binary for the platform that has recieved the
| mail with some safety (if it cant exec a binary write the input to a file
| in $HOME/mail).
| I started some work on a perl program to do this, but that counter acts
| some of the savings one gains from using procmail due to the overhead of
| starting perl.
That's like hoisting a Howitzer over your head to swat a fly.
| Has anyone had this problem before (I can't be the first)? Does anyone
| have a shell script to do something like this? I can just put three lines
| in my .forward one for each system and what fails fails, and what works
| works (This shounds like a BAD THING(tm) to me)?
It used to be in the FAQ in the procmail distribution. Essentially, it
went like this, assuming that the sh that ran your .forward would always have
a path that included uname, or that uname would have the same absolute path
on all three machines:
"|IFS"' '&&exec $HOME/bin/`uname -s`/bin/procmail #oxenreid"
| Procmail is located in the following directories for each platform.
| OSF = $HOME/bin/osf/bin
| Sol = $HOME/bin/sol/bin
| Sol X86 = $HOME/bin/solx86/bin
Make sure that you have symlinks to those directories (or mkdir new ones,
or change the names of the existing ones) so that the path component that
names the OS matches the output of uname -s. If a different option of uname
works better for you than -s, use that instead.
But the overhead of running uname for each incoming piece of mail is much
lighter than that of perl.