From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gatech.edu (gatech.edu [130.207.244.244]) by werple.mira.net.au (8.6.12/8.6.9) with SMTP id TAA19865 for ; Mon, 5 Jun 1995 19:40:24 +1000 Received: from math (math.skiles.gatech.edu) by gatech.edu with SMTP id AA01767 (5.65c/Gatech-10.0-IDA for ); Mon, 5 Jun 1995 05:36:16 -0400 Received: by math (5.x/SMI-SVR4) id AA08828; Mon, 5 Jun 1995 05:33:31 -0400 Resent-Date: Mon, 05 Jun 95 10:33:04 +0100 Old-Return-Path: Message-Id: <22836.9506050933@pyro.swan.ac.uk> To: zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: BIG bug! In-Reply-To: "david.sainty@comp.vuw.ac.nz"'s message of "Sun, 04 Jun 1995 19:25:53 +1200." <199506040725.TAA26352@bats.comp.vuw.ac.nz> Date: Mon, 05 Jun 95 10:33:04 +0100 From: P.Stephenson@swansea.ac.uk X-Mts: smtp Resent-Message-Id: <"LV_5Z.0.o92.gziql"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/72 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu david.sainty@comp.vuw.ac.nz wrote: > This bug has a very weird effect that could cause a lot of strife! The > effect appears to be that at the end of .'ing a script (including > login scripts), zsh is likely to jump back into the middle of the > script and start again! This causes infinite loops, or weird errors > with no apparent cause (I could not see where the unmatched " was, > because my login script was being jumped into halfway through a line > with a " near the start!) > > And yeah.... That did take a lot of hunting! But I have so much work > to do, I was just looking for a reason to procrastinate! :-) Thanks for the work on this... You'll be gratified/annoyed to know it only took me a few minutes to track down with the information you gave. These are classic symptoms for exit() being called instead of _exit(), so the culprit had to be the exit for builtins with an exec. The problem was the new code which allows an exec at the end of a subshell turns on CFLAG_EXEC, and the forked variable isn't enough to tell you if you're in a subshell, so I added the explicit test for `subsh'. (Translation: You're likely to get this when doing something like backtick expansion where the last command was a builtin --- that was the case in Dave's script.) Anyway, this disposes of that spurious `return' call on OSF/1 3.0. If anyone still experiences similar problems, let me know a.s.a.p. Looking at the exit in execlist(), it may well be that needs the same treatment. (The symptoms would then show up when ERREXIT was set in a subshell which terminated on an error.) *** Src/exec.c.exit Mon Jun 5 10:16:00 1995 --- Src/exec.c Mon Jun 5 10:16:14 1995 *************** *** 1450,1456 **** if (!forked) { if (cmd->flags & CFLAG_EXEC) ! exit(lastval); if (savelist) { /* Restore variables, freeing the list but not data. */ Savepm savenode; --- 1450,1459 ---- if (!forked) { if (cmd->flags & CFLAG_EXEC) ! if (subsh) ! _exit(lastval); ! else ! exit(lastval); if (savelist) { /* Restore variables, freeing the list but not data. */ Savepm savenode; -- Peter Stephenson Tel: +44 1792 205678 extn. 4461 WWW: http://python.swan.ac.uk/~pypeters/ Fax: +44 1792 295324 Department of Physics, University of Wales, Swansea, Singleton Park, Swansea, SA2 8PP, U.K.