From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6048 invoked from network); 2 Oct 2004 21:24:13 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 2 Oct 2004 21:24:13 -0000 Received: (qmail 89723 invoked from network); 2 Oct 2004 21:24:07 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 2 Oct 2004 21:24:06 -0000 Received: (qmail 18936 invoked by alias); 2 Oct 2004 21:24:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20441 Received: (qmail 18925 invoked from network); 2 Oct 2004 21:24:03 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 2 Oct 2004 21:24:03 -0000 Received: (qmail 89375 invoked from network); 2 Oct 2004 21:24:03 -0000 Received: from moonbase.zanshin.com (64.84.47.139) by a.mx.sunsite.dk with SMTP; 2 Oct 2004 21:24:00 -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 i92LNs6v021685 for ; Sat, 2 Oct 2004 14:23:56 -0700 Date: Sat, 2 Oct 2004 14:23:54 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@sunsite.dk To: zsh-workers@sunsite.dk Subject: Re: More POSIX developments In-Reply-To: <200409271104.i8RB4URU009112@news01.csr.com> Message-ID: References: <200409271104.i8RB4URU009112@news01.csr.com> 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 Finally got a chance to look at this. On Mon, 27 Sep 2004, Peter Stephenson wrote: > The following patch, which I won't commit until we've decided which way > to go, tries to cover the bases by making test work (more) like POSIX > while leaving [[ ... ]] the way it is. The errors now return status 2 > from evalcond, but for backward compatibility [[ ... ]] turns them into > shell errors. I think this would be OK. > I needed to add an extra warning function to choose between the cases > where we have a builtin name and where the code is called internally as > a condition. Does anyone know if there's a reason zwarnnam handles the > absence of a command name in a strange way? I paged through a grep of all the calls to zwarnnam(), and there don't seem to be any that intentionally get passed a NULL first argument, so it probably is just defensive programming. > In other words, could I remove zwarnnamopt and make zwarnnam behave like > that? I think that'd be safe, but I wouldn't object to a second opinion.