Re: Use of zerr() vs. zwarn()

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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