I don't think I could have voiced it better myself. Mitch is absolutely
right here when he says that empty ("") is *not* the same as
non-existant. It may not make perfect sense for SENDER, but for other
variables it may -- indeed, the mere presence (regardless of content) of
the variable is enough for some programs.
Please, Sam, reconsider this code that seems to me to:
a) /not/ operate on the principle of least surprise (thanks, "Courier
User").
b) /not/ follow common convention
c) unintuitive
d) it breaks a bunch of software
Adding the 'unset' directive would allow those people that rely on the
current (broken, IMO) behavior to continue "unsetting" variables.
> 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
>
>
--
Ensign Walnut approaches Dr. Crusher with caution...
Jon Nelson <[EMAIL PROTECTED]>
C and Python Code Gardener
-------------------------------------------------------
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
