From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15694 invoked from network); 29 Sep 2000 16:59:32 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Sep 2000 16:59:32 -0000 Received: (qmail 16249 invoked by alias); 29 Sep 2000 16:58:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12866 Received: (qmail 16236 invoked from network); 29 Sep 2000 16:58:53 -0000 From: "Bart Schaefer" Message-Id: <1000929165834.ZM14923@candle.brasslantern.com> Date: Fri, 29 Sep 2000 16:58:34 +0000 In-Reply-To: <1000928033550.ZM13657@candle.brasslantern.com> Comments: In reply to "Bart Schaefer" "Re: two append bugs?" (Sep 28, 3:35am) References: <20000927154646.B4971@dman.com> <1000928033550.ZM13657@candle.brasslantern.com> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Use of zerr() vs. zwarn() MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 28, 3:35am, Bart Schaefer wrote: } Subject: Re: two append bugs? } } On Sep 27, 3:46pm, Clint Adams wrote: } } } } % echo bla >> t || echo failed } } zsh: permission denied: t } } } } % /bin/echo bla >> t || echo failed } } zsh: permission denied: t } } failed } } It might be possible to get zsh to behave "as if" it had forked in this } circumstance. This would appear to be (as I suspected) a simple case of changing some calls to zerr() to be calls to zwarn() instead. However, there are a number of other places where zerr() is called that would have to change in order to generalize "builtins behave as if forked". There also seem to be a number of inconsistencies in whether zerr() or zwarn() is used for a particular condition. The following is an audit of places where I think the usage *might* need revision. ----------------------------------------------------------------------- Modules/parameter.c:199: zwarn("restricted: %s", value, 0); Should assignment to the `commands' parameter use zerr() when the shell is restricted? (See builtin.c:1605, below) Zle/computil.c:255: zwarnnam(nam, "can only be called from completion function", NULL, 0); Zle/computil.c:1727: zwarnnam(nam, "can only be called from completion function", NULL, 0); Zle/computil.c:2408: zwarnnam(nam, "can only be called from completion function", NULL, 0); Zle/computil.c:2591: zwarnnam(nam, "can only be called from completion function", NULL, 0); Zle/computil.c:2737: zwarnnam(nam, "can only be called from completion function", NULL, 0); Zle/computil.c:2865: zwarnnam(nam, "can only be called from completion function", NULL, 0); Zle/computil.c:3555: zwarnnam(nam, "can only be called from completion function", NULL, 0); Zle/computil.c:3652: zwarnnam(nam, "can only be called from completion function", NULL, 0); init.c:1122: zwarnnam(name, "option valid only in functions called from completion", Should these use zerrnam(), as do completion-only conditions within [[ ... ]] ? Zle/zle_main.c:761: zwarnnam(name, "ZLE cannot be used recursively (yet)", NULL, 0); Hmm, zerrnam()? Zle/zle_thingy.c:400: zwarnnam(name, "can only be called from widget function", NULL, 0); Zle/zle_thingy.c:444: zwarnnam(name, "can only be called from widget function", NULL, 0); Zle/zle_thingy.c:460: zwarnnam(name, "can only be called from widget function", NULL, 0); Zle/zle_thingy.c:611: zwarnnam(name, "widgets can only be called when ZLE is active", Same situation as completion-only ... builtin.c:294: zerr("bad option: -%c", NULL, *arg); Why is passing a bad option to a builtin a fatal error? Just zwarn()? builtin.c:1510: zerr("bad assignment", NULL, 0); This comes from e.g. `typeset \=foo'. Why a fatal error? builtin.c:1584: zerrnam(cname, "%s: can't change type of a special parameter", builtin.c:1886: zerrnam(name, "can't tie a variable to itself", NULL, 0); builtin.c:1939: zerrnam(name, "use unset to remove tied variables", NULL, 0); builtin.c:1998: zerr("not an identifier: %s", asg->name, 0); builtin.c:2240: zerrnam(name, "%s: invalid parameter name", s, 0); builtin.c:2264: zerrnam(name, "%s: invalid element for unset", s, 0); Similarly, it doesn't seem these would need to be fatal. (Other typeset errors are not, but other parameter errors are, e.g. almost anything but autoloading in params.c.) builtin.c:1605: zerrnam(cname, "%s: restricted", pname, 0); builtin.c:2252: zerrnam(name, "%s: restricted", pm->nam, 0); See Modules/parameter.c:199 above builtin.c:3081: zerr(*p == '?' ? "bad option: -%c" : exec.c:2290: zerr("write error: %e", NULL, errno); glob.c:576: zerr("%e: %s", fn, errno); signals.c:544: zerr("timeout", NULL, 0); utils.c:2408: zerr("can't set tty pgrp: %e", NULL, errno); Why call zerr() and then reset errflag = 0, rather than call zwarn()? exec.c:1454: zerr("file mode mismatch on fd %d", NULL, fd1); exec.c:1827: zerr("no such builtin: %s", cmdarg, 0); exec.c:2088: zerr("writing redirection not allowed in restricted mode", NULL, 0); exec.c:2100: zerr("%e", NULL, errno); exec.c:2155: zerr("%s: %e", fn->fd2 == -2 ? "coprocess" : fdstr, errno); 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); These are all in the "builtin should behave like external command" set. exec.c:2678: zerr("%e: %s", s, errno); This is getoutput(). Not sure what should happen here. exec.c:2784: zerr("oops.", NULL, 0); How helpful. exec.c:3238: zerr("%s: function definition file not found", shf->nam, 0); exec.c:3261: zerr("%s: function not defined by file", n, 0); exec.c:3365: zerr("%s: function not defined by file", name, 0); These occur during autoloading. Should they behave like "command not found" for externals, and therefore only be warnings? jobs.c:1214: zwarnnam(name, "-Z is restricted", NULL, 0); Another case where restricted shells might use zerrnam(). 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. -- 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