From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17946 invoked from network); 4 Apr 2003 20:41:58 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 4 Apr 2003 20:41:58 -0000 Received: (qmail 22810 invoked by alias); 4 Apr 2003 20:41:29 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6015 Received: (qmail 22803 invoked from network); 4 Apr 2003 20:41:28 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 4 Apr 2003 20:41:28 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [152.81.1.70] by sunsite.dk (MessageWall 1.0.8) with SMTP; 4 Apr 2003 20:41:27 -0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9CAC96826; Fri, 4 Apr 2003 22:41:27 +0200 (MEST) X-Amavix: Anti-spam check done by SpamAssassin X-Amavix: Anti-virus check done by McAfee X-Amavix: Scanned by Amavix Received: from greux.loria.fr (greux.loria.fr [152.81.2.43]) by macker.loria.fr (Postfix) with ESMTP id AB92668C5; Fri, 4 Apr 2003 22:41:25 +0200 (MEST) Received: from lefevre by greux.loria.fr with local (Exim 3.36 #1 (Debian)) id 191Y05-00022Q-00; Fri, 04 Apr 2003 22:41:25 +0200 Date: Fri, 4 Apr 2003 22:41:25 +0200 From: Vincent Lefevre To: zsh-users@sunsite.dk Subject: Re: Unsetting a variable that was not previously set Message-ID: <20030404204125.GA7801@greux.loria.fr> Mail-Followup-To: zsh-users@sunsite.dk References: <20030404154938.GE16102@greux.loria.fr> <18642.1049472589@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <18642.1049472589@csr.com> X-Mailer-Info: http://www.vinc17.org/mutt/ User-Agent: Mutt/1.5.4i On Fri, Apr 04, 2003 at 17:09:49 +0100, Peter Stephenson wrote: > I think you're probably right, but it's not completely clear. The page > you quote explicitly says: > > EXIT STATUS > > 0 > All name operands were successfully unset. > >0 > At least one name could not be unset. > > Now, if it doesn't exist, it can't be unset, I don't think that a variable needs to exist in order to be unset. I think that 'unset' is just a special status (or "value") for the variable (a bit like 'undef' in Perl). So, we have the following interpretation: > but I think by `unset' they mean `rendered such that it is not set > whether or not it was before', which is your interpretation. and I think that this is the goal of the following sentence to make things clear about this problem: > > "Unsetting a variable or function that was not previously set shall > > not be considered an error and does not cause the shell to abort." > > It doesn't cause the shell to abort currently. The terminology in the > introduction does suggest `error' is more or less synonymous with > `non-zero return code', but I can find no normative indication of > whether this applies to the language used for the special builtins. I could only find http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap01.html Under "EXIT STATUS": "Usually, utilities return zero for successful completion and values greater than zero for various error conditions." -- Vincent Lefèvre - Web: - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA