procmail
[Top] [All Lists]

Bill Moseley's ${$MATCH} problem

1999-01-10 23:23:03
Bill Moseley's questions included forwarding to an address where MATCH
contained not the destination address itself but rather the name of the
variable whose value was the destination address; in other words, he had to
accomplish this action line:

 | eval '"$SENDMAIL"' "$SENDMAILFLAGS" \${$MATCH} ;

which, as I wrote it, requires a semicolon to force a shell because "eval" is
not an executable in $PATH.

Can that be done without a shell, with no forks other than calling the MTA?
 
I can think of two ways, both of which have drawbacks that might be worse
than calling a shell:

1. Instead of a table of values for the variables, each could have its own
INCLUDERC.  Thus, if MATCH extracts VAR1 and VAR1=a(_at_)b(_dot_)c, and if MATCH
extracts VAR2 and VAR2=d(_at_)e(_dot_)f, $MAILDIR/VAR1 could be a one-line file 
reading

  RECIPIENT=a(_at_)b(_dot_)c

and $MAILDIR/VAR2 could be a one-liner reading

  RECIPIENT=d(_at_)e(_dot_)f

Then the code could look something like this:

  INCLUDERC=$MATCH
  :0
  ! $RECIPIENT

The drawback is having all these little files around.

2. Similar to my listname translation game and my old suggestion for
recasing, Bill could have a long string like this [assuming that octothorpes
and commas are not present in the addresses and certainly not in the
variables' names]:

translationstring="VAR1#ad(_at_)dress(_dot_)1,VAR2#ad(_at_)dress(_dot_)2,VAR3#ad(_at_)dress(_dot_)3,\
VAR4#ad(_at_)dress(_dot_)4"

 :0
 * $ translationstring ?? ^^(.*,)?$MATCH#\/[^,]+
 ! $MATCH

It can be a messy string to edit, though, and is limited to LINEBUF.
However, I use that technique heavily and shamelessly.

DWT (heavy and shameless)

<Prev in Thread] Current Thread [Next in Thread>