[ Note: I recently posted this message to the courier-users group. Clearly, it's pertinent here, as well. ]

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?