zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: Re: The `zle' command and traps
Date: Mon, 13 Mar 2000 17:49:03 +0100 (MET)	[thread overview]
Message-ID: <200003131649.RAA00105@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Sven Wischnowsky's message of Mon, 13 Mar 2000 16:07:25 +0100 (MET)


I wrote:

> Bart Schaefer wrote:
> 
> ...
> > That isn't strictly necessary as one can redirect stdout to hide the
> > warning.  However, it'd be nice if zle returned a non-zero status when
> > it fails; try typing
> > 
> > 	zle -R "not echoed" || echo zle failed
> > 
> > and you'll get
> > 
> > 	zle: can only be called from widget function
> > 
> > but not "zle failed".
> 
> Argh! That's a much more general problem: try `continue || echo foo'. And
> 3.0.8 does the same, too.
> 
> And it's connected to my patch for `zcompile' (10106). I have to check 
> that again.

Ok, the real problem was that execsimple() didn't check errflag. And
then there were two functions in loop.c that didn't always leave
state->pc behind the body of the loop.

> Hm. Some builtins sometimes reset errflag and sometimes not. execbuiltin()
> resets errflag if it was set before the call to the function
> implementing the builtin and after that only uses zwarnnam(), not
> zerrnam(). Is it correct to reset errflag in execbuiltin() after the
> call to the function? Or do we have to find all the places where we
> have to reset errflag? Or just replace some calls to zerrnam() with
> calls to zwarnnam(). No patch for that yet.

After a bit of checking... I think in many places where we call
zerrnam() we should really be calling zwarnnam() in functions
implementing builtins. Otherwise a error reported by the builtin will
exits loops and sublists and whatnot. And in some places we may even
have to check if something called from the function for the builtin
might set errflag and the builtin-function has to reset it -- as was
the case for zcompile.


The patch also makes zcompile remove the wordcode file if an error
occured and the file was already created. An oversight.

Bye
 Sven

diff -ru ../z.old/Src/exec.c Src/exec.c
--- ../z.old/Src/exec.c	Mon Mar 13 14:14:41 2000
+++ Src/exec.c	Mon Mar 13 17:38:24 2000
@@ -735,6 +735,9 @@
 {
     wordcode code = *state->pc++;
 
+    if (errflag)
+	return (lastval = 1);
+
     if (code)
 	lineno = code - 1;
 
diff -ru ../z.old/Src/loop.c Src/loop.c
--- ../z.old/Src/loop.c	Mon Mar 13 14:14:44 2000
+++ Src/loop.c	Mon Mar 13 17:10:30 2000
@@ -171,6 +171,7 @@
     popheap();
     cmdpop();
     loops--;
+    state->pc = end;
     return lastval;
 }
 
@@ -394,6 +395,7 @@
     cmdpop();
     popheap();
     loops--;
+    state->pc = end;
     return lastval;
 }
 
diff -ru ../z.old/Src/parse.c Src/parse.c
--- ../z.old/Src/parse.c	Mon Mar 13 14:14:46 2000
+++ Src/parse.c	Mon Mar 13 17:45:00 2000
@@ -2404,6 +2404,7 @@
 	    close(dfd);
 	    zerrnam(nam, "can't open file: %s", *files, 0);
 	    noaliases = ona;
+	    unlink(dump);
 	    return 1;
 	}
 	file = (char *) zalloc(flen + 1);
@@ -2415,17 +2416,19 @@
 	    zfree(file, flen);
 	    zerrnam(nam, "can't read file: %s", *files, 0);
 	    noaliases = ona;
+	    unlink(dump);
 	    return 1;
 	}
 	close(fd);
 	file = metafy(file, flen, META_REALLOC);
 
 	if (!(prog = parse_string(file, 1)) || errflag) {
+	    errflag = 0;
 	    close(dfd);
 	    zfree(file, flen);
-	    zerrnam(nam, "can't read file: %s", *files, 0);
+	    zwarnnam(nam, "can't read file: %s", *files, 0);
 	    noaliases = ona;
-	    errflag  = 0;
+	    unlink(dump);
 	    return 1;
 	}
 	zfree(file, flen);

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~2000-03-13 16:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-13 16:49 Sven Wischnowsky [this message]
2000-03-13 17:08 ` Bart Schaefer
  -- strict thread matches above, loose matches on Subject: below --
2000-03-14 10:35 Sven Wischnowsky
2000-03-14 16:56 ` Bart Schaefer
2000-03-14  9:54 Sven Wischnowsky
2000-03-13 15:07 Sven Wischnowsky

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=200003131649.RAA00105@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.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).