From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@sunsite.dk (Zsh hackers list)
Subject: Re: PATCH: exit status
Date: Sat, 11 Nov 2006 13:13:06 +0000 [thread overview]
Message-ID: <20061111131306.cd0bccd1.p.w.stephenson@ntlworld.com> (raw)
In-Reply-To: <061110212844.ZM5583@torch.brasslantern.com>
On Fri, 10 Nov 2006 21:28:44 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Aside: Here's an actual bug:
>
> zsh -fc 'trap "echo \$?" EXIT; echo ${example?oops}'
>
> The EXIT trap is not called when the shell exits on the error caused
> by the ${var?message} construct.
There are two bugs: we go straight to exit() instead of zexit(), and the
EXIT trap doesn't get run if there has just been an error. Presumably
it needs to be run unconditionally. (In fact, now I think about it, I'm
a little bit suspicious that testing for "errflag" before running a
trap, which is right down in the trap handling code, is ever the right
thing to do.)
There's another bug lurking: the exit might be within a forked
subshell, so I've made it use _exit() in that case.
> (Bash prints "127" in this case;
> also, the exit status of zsh on that construct is 1 rather than 127,
> but I don't know why bash chose 127.)
The only mention I can see in the standard is for a command not found,
which doesn't apply, but I presume status 127 is being used generally to
signal an error in shell processing rather than a command return status.
> On Nov 10, 4:09pm, Peter Stephenson wrote:
> }
> } I can see arguments for both sides; it turns whether you consider the
> } "exit" command itself to have been executed before the exit traps run,
> } which is a bit Zen-like.
>
> Think of it as a C program. If
>
> int question_mark = 0;
> atexit() { printf("%d\n", question_mark); }
> main() { question_mark = exit(3); }
>
> is a valid program and, when run, prints "3", then I'm on your side.
> Otherwise I'm with Cragun.
You certainly wouldn't expect exit() to return to main() after running,
regardless of the point at which atexit() takes place, so I don't think
this is parallel. All of which goes to show that there's no killer
argument (that I've heard).
Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.169
diff -u -r1.169 builtin.c
--- Src/builtin.c 10 Nov 2006 09:59:27 -0000 1.169
+++ Src/builtin.c 11 Nov 2006 13:05:12 -0000
@@ -4413,6 +4413,11 @@
* indicate we shouldn't do any recursive processing.
*/
in_exit = -1;
+ /*
+ * We want to do all remaining processing regardless of preceeding
+ * errors.
+ */
+ errflag = 0;
if (isset(MONITOR)) {
/* send SIGHUP to any jobs left running */
Index: Src/subst.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/subst.c,v
retrieving revision 1.67
diff -u -r1.67 subst.c
--- Src/subst.c 7 Nov 2006 22:47:07 -0000 1.67
+++ Src/subst.c 11 Nov 2006 13:05:16 -0000
@@ -2591,8 +2591,17 @@
if (vunset) {
*idend = '\0';
zerr("%s: %s", idbeg, *s ? s : "parameter not set");
- if (!interact)
- exit(1);
+ if (!interact) {
+ if (mypid == getpid()) {
+ /*
+ * paranoia: don't check for jobs, but there shouldn't
+ * be any if not interactive.
+ */
+ stopmsg = 1;
+ zexit(1, 0);
+ } else
+ _exit(1);
+ }
return NULL;
}
break;
--
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/
prev parent reply other threads:[~2006-11-11 13:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-10 9:40 Peter Stephenson
2006-11-10 15:58 ` Bart Schaefer
2006-11-10 16:09 ` Peter Stephenson
2006-11-11 5:28 ` Bart Schaefer
2006-11-11 13:13 ` Peter Stephenson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061111131306.cd0bccd1.p.w.stephenson@ntlworld.com \
--to=p.w.stephenson@ntlworld.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).