Use of zerr() vs. zwarn()

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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