Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: PATCH: suggestion for new condition



Bart Schaefer wrote (in private mail):

> On Jan 28,  9:00am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: suggestion for new condition
> }
> } Bart Schaefer wrote:
> } 
> } > OK, cool, now dumb question number two:  Why does ${(t)param} ignore the
> } > setting of the `nounset' option?
> } 
> } I don't understand this question. How should we use the setting of
> } nounset?
> 
> For any of the previously existing variable flags x, ${(x)notset} gives an
> error when `setopt nounset'.  However:
> 
> } I wanted it to be slightly modeled after `$+param' which also 
> } seems to ignore nounset.
> 
> That's a valid answer to the question "why?" but leads to the next question
> "is that how it _should_ work?"
> 
> The only reason to use $+param is to test whether param is set, so it
> would be silly for it to ever generate an error.  The main reason for
> using ${(t)param}, though, is to find out the type of the param.
> 
> You can always ask whether a parameter exists or not.  But if the param
> doesn't exist, its type is not merely empty; it's undefined, just as its
> value is undefined.  I think the reason for `nounset' is to make "not
> defined" different from "empty" (albeit in a rather brutal fashion), so
> I think the `nounset' test should apply.  Consistency, and all that.

Ok, I'm convinced.

Bye
 Sven

--- os/subst.c	Wed Jan 27 13:53:56 1999
+++ Src/subst.c	Thu Jan 28 10:17:08 1999
@@ -1017,11 +1017,11 @@
 		    val = dyncat(val, "-export");
 		if (f & PM_UNIQUE)
 		    val = dyncat(val, "-unique");
+		vunset = 0;
 	    } else
 		val = dupstring("");
 
 	    v = NULL;
-	    vunset = 0;
 	    isarr = 0;
 	}
     }

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx



Messages sorted by: Reverse Date, Date, Thread, Author