Personally I think "auto-unsetting" empty vars. Is not right. Can I make a case for my opinion?
A non-existant shell variable equating to "" is not the same as the variable not existing. From what I have seen (and comments read) many programs rely on the existance tests - the test is common in most languages (is_set / is_defined / defined / etc.) as is the specific ability to unset a variable. In fact iirc, someone was talking before about adding an unset command to maildrop (requiring parenthesis and made comment that it wouldn't be that hard. Was this a recent addition? I've seen people stating that "X" used to work and now it doesn't... but I don't know first hand so I'm asking - is there anyone opposed to changing this behaviour? As maildrop is not persistant (it is launched and terminated for each delivery) I don't see the benefit to this cleanup process particlarly when I consider the number of times people have to resort to calling external programs or altering programs for what appears to be a non-standard procedure. Even standard shells avoid this (man bash AND man sh): "A parameter is set if it has been assigned a value. The null string is a valid value. Once a variable is set, it may be unset only by using the unset builtin command (see SHELL BUILTIN COMMANDS below)." In SQL, "" is not NULL... Was there a reason this was done? Does it outweigh the problems it seems to cause? Thanks. m/ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Courier User Sent: Tuesday, January 13, 2004 5:46 PM To: [EMAIL PROTECTED] Subject: [courier-users] Re: Does courier / maildrop unset SENDER if it's empty? Sam Varshavchik <[EMAIL PROTECTED]> writes: > Courier User writes: > > >> Could someone (Sam?) explain why that 'delete' statement exists? Is >> there part of maildrop or courier that depends on this odd behavior? > > Because if variable FOO is not defined, $FOO defaults to an empty string. > > Logically, the converse should also be true. But the converse varies greatly from the way that most software that I know of functions. It seems contrary to "the principle of least surprise" ("PoLS") to have A be equivalent to B, instead of C: A: (in maildrop) SENDER="" B: (in an xfilter program) getenv("SENDER") == NULL /* contrary to PoLS */ C: (in an xfilter program) getenv("SENDER") != NULL /* adheres to PoLS */ In other words, in most software I know of, A => C. But in maildrop, A => B. -- Courier User [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
