So do you recommend that I don't use it at all? If it appears to
be working for me, then is it safe? Are these "specific compiles"
always broken, or just sometimes broken (unpredictably)?
As for variable scoping, try this. I get "MYVAR is foo". Notice the
"Forking" line. I think any variables set by a child won't be seen
by the parent, if typical UNIX fork() mechanisms are used.
--------------- start ---------------
VERBOSE=on
MYVAR="foo"
:0c
{
MYVAR="bar"
:0
/dev/null
}
LOG="
MYVAR is $MYVAR
"
:0
/dev/null
--------------- end ---------------
procmail: [17437] Fri Feb 20 15:21:03 2004
procmail: Assigning "MYVAR=foo"
procmail: Forking "procmail"
procmail: [17438] Fri Feb 20 15:21:03 2004
procmail: Assigning "MYVAR=bar"
procmail: Assigning "LASTFOLDER=/dev/null"
procmail: Opening "/dev/null"
Folder: /dev/null 0
procmail: Assigning "LOG=
MYVAR is foo
"
MYVAR is foo
procmail: Assigning "LASTFOLDER=/dev/null"
procmail: Opening "/dev/null"
Folder: /dev/null 0
-----Original Message-----
From: Dallman Ross [mailto:dman(_at_)nomotek(_dot_)com]
Sent: Friday, February 20, 2004 3:07 PM
To: procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
Subject: Re: varname=| construct broken?
On Fri, Feb 20, 2004 at 02:57:55PM -0700, Ian D. wrote:
I think I originally had my assignment inside the block of a copy and
then tried to use the variable later, but I guess the scope of the
variable is just that block. I then turned on verbose and noticed the
assignment appeared to be null, so I simplified my case to demonstrate
the null assignment in the log when in fact my problem was the scoping
issue. The logs are quite misleading. Sorry to have wasted your time.
Well, I don't think anybody's time has been wasted, fwiw. It's incorrect
to say that the var is not persistent beyond the nested block in which
you might have created it. In procmail, vars, once created, are "global."
It's a flat language.
The point was stated well enough by Bart. The VAR|program syntax
on the action line will not always work for specific compiles of
the program. This is a known bug, and can indeed be dangerous
(random memory destruction).
--
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail