| > Tony Jago <tony(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au> writes:
| > > I am using procmail v3.11pre4 1995/10/29 so I guess thats not the
| > > problem. This is what I have been using to test it:
| > ...
| > > If I use this script:
| > >
| > > DUDE="$@"
Philip Guenther answered,
| > To quote the procmailrc(5) manpage's BUGS section:
| >
| > BUGS
| > ... When the -a or -m options are
| > used, "$@" will expand to respectively the specified argu-
| > ment (list); but only when passed as in the argument list to
| > a program.
Tony wrote again,
| Thanks for your help so-far Philip,
|
| I have changes my script to:
|
| LOGFILE=/tmp/logger
| VERBOSE=yes
|
| :0
| | echo "$@" > /tmp/result
|
| and it still does not work!
No, it doesn't work because ">" is in $SHELLMETAS, so procmail forks a shell,
and that shell has its own idea of what $1, $2, $*, and $@ are. "$@" works
properly only if procmail runs the program itself.
Try this:
:0bi
* $ !${1+!}
ARGS=| echo "$@"
:0Abi:/tmp/result.lock
| echo "$ARGS" > /tmp/result
It's not exactly the same but it's close. (I used `b' rather than `h'
because I take it that you're working with test messages where the bodies
tend to be shorter than the heads.)
Or try this:
REALLOGFILE=$LOGFILE
LOGFILE=/tmp/result
LOG="`echo "$@"
`
LOGFILE=$REALLOGFILE
These both assume that there is a /bin/echo executable on your system (or an
executable named echo somewhere in $PATH), even if it is just a script that
passes its parameters to some shell's built-in echo.