From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29784 invoked from network); 22 Sep 2004 15:28:31 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 22 Sep 2004 15:28:31 -0000 Received: (qmail 33479 invoked from network); 22 Sep 2004 15:28:23 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 22 Sep 2004 15:28:23 -0000 Received: (qmail 22428 invoked by alias); 22 Sep 2004 15:28:20 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20400 Received: (qmail 22403 invoked from network); 22 Sep 2004 15:28:18 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 22 Sep 2004 15:28:18 -0000 Received: (qmail 33234 invoked from network); 22 Sep 2004 15:28:18 -0000 Received: from moonbase.zanshin.com (64.84.47.139) by a.mx.sunsite.dk with SMTP; 22 Sep 2004 15:28:15 -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 i8MFS3Sx014611; Wed, 22 Sep 2004 08:28:03 -0700 Date: Wed, 22 Sep 2004 08:28:03 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@sunsite.dk To: "Sean C. Farley" cc: zsh-workers@sunsite.dk Subject: Re: PATCH: zsh-4.2.1: unset does not follow spec In-Reply-To: <20040922091323.V45751@thor.farley.org> Message-ID: References: <20040922091323.V45751@thor.farley.org> MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="0-51444878-1095865411=:60126" Content-ID: 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-51444878-1095865411=:60126 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: On Wed, 22 Sep 2004, Sean C. Farley wrote: > Recently, I read that FreeBSD's /bin/sh fails: > http://www.freebsd.org/cgi/query-pr.cgi?pr=standards/45738 > the IEEE Std 1003.1-2001: > http://www.opengroup.org/onlinepubs/007904975/utilities/unset.html > when it comes to the builtin unset. tcsh and bash do follow it. I don't see how zsh "fails" this specification. EXIT STATUS 0 All name operands were successfully unset. >0 At least one name could not be unset. 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. After all, if it isn't set, you can't UNset it, can you? It doesn't say "0 if all name operands end up unset after this is finished, regardless of their previous state" (which is how bash and tcsh appear to interpret it). I'm going to ask about this on the austin-group list. It'll give them something to discuss that they might actually come to agreement on. --0-51444878-1095865411=:60126 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="zsh.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20040922100331.K60126@thor.farley.org> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="zsh.patch" LS0tIFNyYy9idWlsdGluLmMub3JpZwlGcmkgQXVnIDEzIDA1OjIyOjQyIDIw MDQNCisrKyBTcmMvYnVpbHRpbi5jCVdlZCBTZXAgMjIgMDk6NDQ6MDQgMjAw NA0KQEAgLTI2MzgsOSArMjYzOCw5IEBADQogCQlyZXR1cm52YWwgPSAxOw0K IAkgICAgfQ0KIAl9DQotCS8qIElmIHdlIGRpZG4ndCBtYXRjaCBhbnl0aGlu Zywgd2UgcmV0dXJuIDEuICovDQorCS8qIElmIHdlIGRpZG4ndCBtYXRjaCBh bnl0aGluZywgd2UgcmV0dXJuIDAuICovDQogCWlmICghbWF0Y2gpDQotCSAg ICByZXR1cm52YWwgPSAxOw0KKwkgICAgcmV0dXJudmFsID0gMDsNCiAJcmV0 dXJuIHJldHVybnZhbDsNCiAgICAgfQ0KIA0KQEAgLTI2NjEsNyArMjY2MSw3 IEBADQogCQkgICAgICBnZXRoYXNobm9kZTIocGFyYW10YWIsIHMpIDoNCiAJ CSAgICAgIHBhcmFtdGFiLT5nZXRub2RlKHBhcmFtdGFiLCBzKSk7DQogCWlm ICghcG0pDQotCSAgICByZXR1cm52YWwgPSAxOw0KKwkgICAgcmV0dXJudmFs ID0gMDsNCiAJZWxzZSBpZiAoKHBtLT5mbGFncyAmIFBNX1JFU1RSSUNURUQp ICYmIGlzc2V0KFJFU1RSSUNURUQpKSB7DQogCSAgICB6ZXJybmFtKG5hbWUs ICIlczogcmVzdHJpY3RlZCIsIHBtLT5uYW0sIDApOw0KIAkgICAgcmV0dXJu dmFsID0gMTsNCkBAIC0zMDU2LDkgKzMwNTYsMTcgQEANCiAJCXJldHVybnZh bCA9IDE7DQogCSAgICB9DQogCX0NCi0JLyogSWYgd2UgZGlkbid0IG1hdGNo IGFueXRoaW5nLCB3ZSByZXR1cm4gMS4gKi8NCi0JaWYgKCFtYXRjaCkNCi0J ICAgIHJldHVybnZhbCA9IDE7DQorCS8qDQorCSAqIElmIHdlIGRpZG4ndCBt YXRjaCBhbnl0aGluZywgd2UgcmV0dXJuIDAgZm9yIGZ1bmN0aW9ucyBhbmQg MSBmb3INCisJICogYWxsIG90aGVyIGhhc2ggdHlwZXMuDQorCSAqLw0KKwlp ZiAoIW1hdGNoKSB7DQorCSAgICBpZiAoT1BUX0lTU0VUKG9wcywnZicpKSB7 DQorCQlyZXR1cm52YWwgPSAwOw0KKwkgICAgfSBlbHNlIHsNCisJCXJldHVy bnZhbCA9IDE7DQorCSAgICB9DQorCX0NCiAJcmV0dXJuIHJldHVybnZhbDsN CiAgICAgfQ0KIA0KQEAgLTMwNjksNyArMzA3NywxMSBAQA0KIAkgICAgaHQt PmZyZWVub2RlKGhuKTsNCiAJfSBlbHNlIHsNCiAJICAgIHp3YXJubmFtKG5h bWUsICJubyBzdWNoIGhhc2ggdGFibGUgZWxlbWVudDogJXMiLCAqYXJndiwg MCk7DQotCSAgICByZXR1cm52YWwgPSAxOw0KKwkgICAgaWYgKE9QVF9JU1NF VChvcHMsJ2YnKSkgew0KKwkJcmV0dXJudmFsID0gMDsNCisJICAgIH0gZWxz ZSB7DQorCQlyZXR1cm52YWwgPSAxOw0KKwkgICAgfQ0KIAl9DQogICAgIH0N CiAgICAgdW5xdWV1ZV9zaWduYWxzKCk7DQo= --0-51444878-1095865411=:60126--