From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26834 invoked from network); 30 Sep 2000 16:43:29 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 Sep 2000 16:43:29 -0000 Received: (qmail 17582 invoked by alias); 30 Sep 2000 16:42:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12867 Received: (qmail 17575 invoked from network); 30 Sep 2000 16:42:55 -0000 From: "Bart Schaefer" Message-Id: <1000930164238.ZM15729@candle.brasslantern.com> Date: Sat, 30 Sep 2000 16:42:38 +0000 In-Reply-To: <1000929165834.ZM14923@candle.brasslantern.com> Comments: In reply to "Bart Schaefer" "Use of zerr() vs. zwarn()" (Sep 29, 4:58pm) References: <20000927154646.B4971@dman.com> <1000928033550.ZM13657@candle.brasslantern.com> <1000929165834.ZM14923@candle.brasslantern.com> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: Use of zerr() vs. zwarn() MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 29, 4:58pm, Bart Schaefer wrote: } Subject: Use of zerr() vs. zwarn() } } init.c:1122: zwarnnam(name, "option valid only in functions called from completion", } Should these use zerrnam(), as do completion-only conditions within } [[ ... ]] ? Judging from the indentation on the line following the call to zwarnnam(), I suspect that this originally *was* a call to zerrnam() and was changed to zwarnnam() at some point in the past, but I can't find a zsh-workers article in the archive to confirm. (Maybe it was in a uuencoded patch; it predates my first local import of 3.1.x, which I believe was 3.1.4.) This makes me inclined to leave this whole sub-category alone, at least until there's been some feedback. } exec.c:1454: zerr("file mode mismatch on fd %d", NULL, fd1); This one could be problematic because it's buried in addfd(), so only errflag propagates the error ... but in fact it happens early enough that zsh hasn't forked yet, so both builtins and external commands behave the same. And since it only occurs for multios, there's no issue with sh/ksh emulations. So it can stay as is. } exec.c:2100: zerr("%e", NULL, errno); This one happens when zsh fails to process a here-document. This should never happen, really, but could if e.g. [[ ! -w $TMPPREFIX:h ]]. It's probably harmless to change this to zwarn(), but I wanted to point it out in particular because it's such an unusual event. } exec.c:2876: zerr("doesn't look like your system supports FIFOs.", NULL, 0); } exec.c:2917: zerr("can't open %s: %e", pnam, errno); } exec.c:2678: zerr("%e: %s", s, errno); These three all happen during prefork() and therefore presumably already are the same for builtins and externals. I don't think it would hurt to change them to zwarn(), but I'd like other opinions. } exec.c:2784: zerr("oops.", NULL, 0); } How helpful. This is in parsecmd(). Does somebody know what the actual error is? It looks like some kind of parse problem -- either a missing close paren or too many open parens -- but apparently that should be impossible? } exec.c:3365: zerr("%s: function not defined by file", name, 0); This one is a bit odd because it can be called in a context where there's no `lastval' returned. This means functions like chpwd and precmd, or zftp_progress, or various functions called from old compctls. Presumably in those cases we *do* want errflag set? } jobs.c:1214: zwarnnam(name, "-Z is restricted", NULL, 0); } Another case where restricted shells might use zerrnam(). I'm now of the mind to leave this one alone, simply because it makes no difference whether "jobs -Z" succeeds. } signals.c:699: zerr("can't trap SIG%s in interactive shells", sigs[sig], 0); } Doesn't seem serious enough to be a fatal error. This one also brings up the question of whether enableshfuncnode() (in hashtable.c) should avoid sigtrapped[signum] |= ZSIG_FUNC in the event that settrap() should fail. In any case, the fact that this is called from places other than builtin commands makes me wonder whether (1) we rely on errflag becoming set (it doesn't appear so, but ...) or (2) the tests this is doing that lead to that error, ought to be done somewhere else instead. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net