On Sat, 27 Mar 2004, 13:11 GMT-06 David W. Tamkin wrote:
Robert, your interpretation of the logfile entry is incorrect. The line
in the logfile doesn't mean that the variables aren't expanded: it means
that something other than procmail did the expansion.
When procmail finds a shell metacharacter -- and on a system like yours,
where procmail was compiled with /bin/test nonexistent, procmail
considers the word "test" a shell metacharacter -- and passes the
command line to a shell, procmail lets the shell expand the variables.
The logfile reports the command line passed to the shell, showing the
variables by their names instead of their substituted values. It can
make a difference sometimes: for example, "$$" will be the shell's PID
rather than procmail's, and $- will be (in sh-like shells) the shell's
options rather than $LASTFOLDER. But a variable with an unreserved name
like TEST or av_REQUIRED_DIR will be exported and will have the same
value whether procmail runs the command or hands it to $SHELL.
Yes, I should rather have said "may not work as expected" and
something like "did not expand on the procmail layer". Nevertheless, I
have now returned to my original form
* $ ! ?"$TEST -d \"$av_REQUIRED_DIR\""
which does work as expected on all cases, expanding the variable names
on the procmail layer and not invoking an extra shell.
However, I am keeping the form you suggested on commands where test
is not involved, like
* ? mimencode -u "$av_BASE64FILE" -o "$av_VIRUSFILE"
The reason you still get a failure to match is that the directory does
exist;
Sure - that is the intention of the routine in question
('av_mkdir.inc') -
procmail: No match on ! "/usr/bin/test -d /home/roal/mail/TRASH/viruses/EXE"
is expected to be the normal case. Only one time at all, when the
directory in question has not yet been created, the result should be
procmail: Non-zero exitcode (1) from "/usr/bin/test"
instead and then that directory will be created.
Robert, look, you're trying to write portable code that will work on
systems with /bin/test and systems without /bin/test. Let me make this
suggestion:
Copy or symlink /usr/bin/test to /bin/test;
compile procmail into a different directory from where it is now, but
make sure that it has /usr/bin in its default PATH;
rm /bin/test.
Thereafter, you can try out your code with a version of procmail that
treats "test" as a shell metacharacter and with one that searches $PATH
for a binary named "test".
yes, I like this suggestion, but currently don't find so much time to
spend on dealing with different procmail binaries. I am almost glad to
have a non-typical binary on the RedHat systems where I am testing my
recipes intensively, so I can take that special situation into
account.
best,
rob.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail