zsh-workers
 help / color / mirror / code / Atom feed
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/


      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).