From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6100 invoked from network); 23 Sep 2004 07:55:44 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 23 Sep 2004 07:55:44 -0000 Received: (qmail 98441 invoked from network); 23 Sep 2004 07:55:37 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 23 Sep 2004 07:55:37 -0000 Received: (qmail 4418 invoked by alias); 23 Sep 2004 07:55:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20404 Received: (qmail 4403 invoked from network); 23 Sep 2004 07:55:21 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 23 Sep 2004 07:55:21 -0000 Received: (qmail 97725 invoked from network); 23 Sep 2004 07:54:46 -0000 Received: from moonbase.zanshin.com (64.84.47.139) by a.mx.sunsite.dk with SMTP; 23 Sep 2004 07:54:44 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.13.1/8.13.1) with ESMTP id i8N7shkU006371 for ; Thu, 23 Sep 2004 00:54:43 -0700 Date: Thu, 23 Sep 2004 00:54:43 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@sunsite.dk To: zsh-workers@sunsite.dk Subject: Re: PATCH: zsh-4.2.1: unset does not follow spec In-Reply-To: <20040922205546.1fb37a99@buddha.localdomain.de> Message-ID: References: <20040922091323.V45751@thor.farley.org> <20040922205546.1fb37a99@buddha.localdomain.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 On Wed, 22 Sep 2004, Matthias B. wrote: > On Wed, 22 Sep 2004 08:28:03 -0700 (PDT) Bart Schaefer > wrote: > > > It appears to me that FreeBSD and Zsh are interpreting "could not be > > unset" to include variables that were not set in the first place. > > Arguing over the letter of a specification is not useful. Firstly, I was stating a theory, not arguing a position. Secondly, one can't start from the premise of "X does not follow the letter of the specification" and then dismiss all discussion of what the letter _is_. > When your boss tells you to hammer a nail into the wall at spot X, you > go there and find that there is already a nail, what do you do? Wrong question. When your boss tells you to pull a nail out of the wall at spot X and bring it to him, and you go there and find that there is no nail to pull, what do you do? Do you think he'll appreciate it if you never tell him why he didn't get his nail? That's not the right question either, but it's closer. The right question is more like: When your boss tells you to pull a nail out of the wall at spot X, and you go there and find that there is no nail to pull and no hole where one used to be, how do you find out whether your boss cares about the hole? Nevertheless: > BTW, the behaviour of unset should, I think, depend on the UNSET option. > If UNSET is off, then unset should report an error if the variable is > already unset. This is actually what I was going to suggest. (Is it time for "emulate posix"?)