From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2138 invoked from network); 23 Sep 2004 16:16:36 -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 16:16:36 -0000 Received: (qmail 81055 invoked from network); 23 Sep 2004 16:16:30 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 23 Sep 2004 16:16:30 -0000 Received: (qmail 23190 invoked by alias); 23 Sep 2004 16:15:45 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20407 Received: (qmail 23172 invoked from network); 23 Sep 2004 16:15:43 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 23 Sep 2004 16:15:43 -0000 Received: (qmail 79094 invoked from network); 23 Sep 2004 16:14:46 -0000 Received: from moonbase.zanshin.com (64.84.47.139) by a.mx.sunsite.dk with SMTP; 23 Sep 2004 16:14: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 i8NGEfr0031650 for ; Thu, 23 Sep 2004 09:14:41 -0700 Date: Thu, 23 Sep 2004 09:14:41 -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: <23277.1095931599@trentino.logica.co.uk> Message-ID: References: <20040922091323.V45751@thor.farley.org> <20040922205546.1fb37a99@buddha.localdomain.de> <23277.1095931599@trentino.logica.co.uk> 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 Thu, 23 Sep 2004, Oliver Kiddle wrote: > The specification looks fairly clear to me (zsh is wrong) On Thu, 23 Sep 2004, Geoff Clare wrote: > > I would say that a non-zero exit for "unset" is definitely an error, but > the standard is unclear as to whether "unset" is required to treat an > attempt to unset a variable that was not previously set as an ordinary > error (as opposed to a "utility syntax error", which is definitely not > allowed). > > -- > Geoff Clare, opengroup.org I don't really have a strong opinion either way (I can't remember EVER testing the exit status of "unset" but I suppose it could affect the shell in the case of "setopt errexit"), but I don't think it's as cut and dried as it should be. (Back to Oliver) On Thu, 23 Sep 2004, Oliver Kiddle wrote: > > > (Is it time for "emulate posix"?) > > Possibly. > > How would it differ from "emulate sh"? At the moment, it might not. If, however, we were to discover a case where POSIX specifies behavior that differs from historic /bin/sh behavior, we might want a plain way to get either one. Also, although "emulate" has so far been limited to setting options, it might be worth considering whether it should also modify the environment, e.g., exporting POSIXLY_CORRECT or UNIX95 or whatever. However, what it exported would depend on compile-time configuration, which although it could be OS-specific could not be architecture-specific, making trouble on binary-compatible platforms that use different techniques to achieve POSIX conformance. So, I'm not sure.