In trying to debug some problems in a program that I'm invoking via
xfilter in maildrop, I have realized that the following construct in
a maildrop recipe file doesn't do exactly what I expected:
VARIABLE=""
In this case, maildrop completely removes the environment variable
called "VARIABLE". I was expecting that it would cause that
variable to exist and to be bound to an empty string.
The following snippet of code in the SetVar function in
maildrop/varlist.C illustrates this behavior:
if (value.Length() == 0) // Delete variable
{
Variable **v;
for (v= &varlist[n]; *v; v= &(*v)->next)
if ( (*v)->name == var )
{
Variable *vv= (*v);
(*v)= vv->next;
delete vv;
break;
}
return;
}
Obviously, this code was written for a reason. I'm wondering what
that reason is, since a non-existent environment variable is not the
same as one that exists and contains an empty string.
Even though maildrop appears to treat these two cases identically,
child processes invoked via xfilter and other means could have
problems with this. This happens because environment variables are
inherited by child processes, which in the general case cannot be
counted on to look at these two instances as being equivalent ...
and in quite a few common cases, they do not.
For one example out of many, this behavior could cause a problem in
any C program that might be called via xfilter, because the standard
getenv() library function in C returns NULL if the environment
variable does not exist, but it returns a pointer to an empty string
in the case that it does (and is set to "").
What do you folks think of the following proposal (since I'm already
working [albeit slowly] on a set of new functions for maildrop):
Invoking the following within maildrop would cause the variable
to be set to an empty string instead of being deleted.
VARIABLE=""
A new function called unset() or something similar would be used to
completely remove a variable from the environment; i.e.,
unset(VARIABLE)
Inside of maildrop itself, these two constructs would behave
identically, since the program seems to not make a distinction
between these two cases. However, inside of programs invoked via
xfilter etc., these two constructs would cause different effects.
And this way, at least the behavior will be clearer to the writers
and maintainers of maildrop recipes.
Thoughts?
--
Courier User
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
