* Function code breaking out of if then ...fi @ 2012-11-02 9:09 Michal Maruska 2012-11-02 21:39 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Michal Maruska @ 2012-11-02 9:09 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 589 bytes --] Hello, I wonder if the following behaviour is a bug, or simply my wrong expectation: This script, assuming the globbing fails, and I'm not using NULL_GLOB, does not bother finishing the commands in the "then ....fi" block, instead continues after "fi". #! /usr/bin/zsh -feu fn () { foreach sum (non-existing*) {echo $sum} } if true; then fn exit 0 fi echo tragedy exit -1 --------------------------- I was advised (on IRC) to use { fn } always { TRY_BLOCK_ERROR=0 } But I'd like to see the behaviour documented in the chapters not about " {} always {} ". Thank you ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-02 9:09 Function code breaking out of if then ...fi Michal Maruska @ 2012-11-02 21:39 ` Bart Schaefer 2012-11-05 8:22 ` Han Pingtian 2012-11-05 14:29 ` Peter Stephenson 0 siblings, 2 replies; 12+ messages in thread From: Bart Schaefer @ 2012-11-02 21:39 UTC (permalink / raw) To: zsh-workers On Nov 2, 10:09am, Michal Maruska wrote: } } I wonder if the following behaviour is a bug, or } simply my wrong expectation: } } This script, assuming the globbing fails, and I'm not using NULL_GLOB, } does not bother finishing the commands in the "then ....fi" block, } instead continues after "fi". This doesn't really have anything to do with the function. The same thing happens with if true; then echo non-existing* exit 0 fi What slightly surprises me is that a glob failure isn't considered an error for purposes of ERR_EXIT (the -e option in your #! line). I would have expected the whole script to quit at that point, but I guess glob errors are not treated as command failures because the command never executes in the first place. However, what *is* happening is that a glob failure in a complex command acts in the manner of a "break" statement. This is to prevent runaway loops spewing the same globbing error ad infitinum; I remember that this change was made a long while ago, but I don't recall exactly when, and it appears it would take a major excavation to find it in the ChangeLog. The trouble of course is that a "break" statement isn't supposed to have any effect in the body of an "if", but although actually using "break" in that context is not allowed, the same logic isn't applied when the internal error-flag gets set by a glob failure, and zsh bails out of the if-body the same way it would from a loop-body. Whether this is a bug could be argued either way. NOMATCH occupies a sort of grey area between parser-detectable syntax error and run-time command failure. } I was advised (on IRC) to use } } { fn } always { TRY_BLOCK_ERROR=0 } This is a workaround, because it introduces a new complex command (the braced expression to the left of "always") and gives you a hook for clearing the error before it affects any surrounding complex command. But that would be the wrong place to document this behavior of NOMATCH. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-02 21:39 ` Bart Schaefer @ 2012-11-05 8:22 ` Han Pingtian 2012-11-05 9:31 ` Han Pingtian 2012-11-05 14:29 ` Peter Stephenson 1 sibling, 1 reply; 12+ messages in thread From: Han Pingtian @ 2012-11-05 8:22 UTC (permalink / raw) To: zsh-workers On Fri, Nov 02, 2012 at 02:39:11PM -0700, Bart Schaefer wrote: > On Nov 2, 10:09am, Michal Maruska wrote: > } > } I wonder if the following behaviour is a bug, or > } simply my wrong expectation: > } > } This script, assuming the globbing fails, and I'm not using NULL_GLOB, > } does not bother finishing the commands in the "then ....fi" block, > } instead continues after "fi". > > This doesn't really have anything to do with the function. The same > thing happens with > > if true; > then > echo non-existing* > exit 0 > fi > > What slightly surprises me is that a glob failure isn't considered an > error for purposes of ERR_EXIT (the -e option in your #! line). I > would have expected the whole script to quit at that point, but I guess > glob errors are not treated as command failures because the command > never executes in the first place. > On my latop, if use 'echo non-existing*' in the if command, the script will exit immediately, looks like the glob failure is considered an error of ERR_EXIT. And changing to { echo non-existing* } always { TRY_BLOCK_ERROR=0 } doesn't help, it still exits immediately. In the contrast, using 'fn' won't trigger ERR_EXIT. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-05 8:22 ` Han Pingtian @ 2012-11-05 9:31 ` Han Pingtian 0 siblings, 0 replies; 12+ messages in thread From: Han Pingtian @ 2012-11-05 9:31 UTC (permalink / raw) To: zsh-workers On Mon, Nov 05, 2012 at 04:22:50PM +0800, Han Pingtian wrote: > On my latop, if use 'echo non-existing*' in the if command, the > script will exit immediately, looks like the glob failure is > considered an error of ERR_EXIT. And changing to > > { echo non-existing* } always { TRY_BLOCK_ERROR=0 } > > doesn't help, it still exits immediately. In the contrast, using 'fn' > won't trigger ERR_EXIT. But the failure of 'echo non-existing*' won't trigger a 'trap "..." ZERR' command at the sametime, this isn't like a normal failing command will do ... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-02 21:39 ` Bart Schaefer 2012-11-05 8:22 ` Han Pingtian @ 2012-11-05 14:29 ` Peter Stephenson 2012-11-05 14:55 ` Peter Stephenson 1 sibling, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2012-11-05 14:29 UTC (permalink / raw) To: zsh-workers n Fri, 02 Nov 2012 14:39:11 -0700 Bart Schaefer <schaefer@brasslantern.com> wrote: > On Nov 2, 10:09am, Michal Maruska wrote: > } > } I wonder if the following behaviour is a bug, or > } simply my wrong expectation: > } > } This script, assuming the globbing fails, and I'm not using > NULL_GLOB, } does not bother finishing the commands in the > "then ....fi" block, } instead continues after "fi". > > What slightly surprises me is that a glob failure isn't considered an > error for purposes of ERR_EXIT (the -e option in your #! line). I > would have expected the whole script to quit at that point, but I > guess glob errors are not treated as command failures because the > command never executes in the first place. > > However, what *is* happening is that a glob failure in a complex > command acts in the manner of a "break" statement. It's not really like a break, it's like (well, is) a global error flag --- but the error status gets reset at the top level command loop, which we reach in a script after the end of a set of complex commands --- but only right at the end, when we're reading a new (possibly complex, arbitrarily nested) command from the script. I think actually what's going on could be considered a bug which is an oversight for the case of scripts. If the code was running a function, the failure would cause it to skip right to the end of the function, indeed any arbitrarily nested hierarchy of functions. If we took the rough equivalence between functions and scripts seriously, any hard error (zerr() or zerrnam()) would cause a script to exit in the same way. Interactively, the error flag would still get reset but non-interactively it wouldn't. I don't see anything in the documentation to suggest that the top-level command loop should be special non-interactively in the way it currently is. Indeed, when documenting try- and always-blocks, I wrote: An `error' in this context is a condition such as a syntax error which causes the shell to abort execution of the current func‐ tion, script, or list. ^^^^^^ which is clearly not true. If there's a more fundamental description of what happens on an error, I don't know where it is. Indeed, it looks to me that without this the shell is violating the "shall exit" terms of POSIX, section 2.8.1 of the shell command language. To use the example they give, this script echo "${x!y}" echo Got here shouldn't print anything apart from the error message, but does. pws ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-05 14:29 ` Peter Stephenson @ 2012-11-05 14:55 ` Peter Stephenson 2012-11-05 16:08 ` Peter Stephenson 2012-11-09 22:52 ` Peter Stephenson 0 siblings, 2 replies; 12+ messages in thread From: Peter Stephenson @ 2012-11-05 14:55 UTC (permalink / raw) To: zsh-workers On Mon, 05 Nov 2012 14:29:42 +0000 Peter Stephenson <p.stephenson@samsung.com> wrote: > It's not really like a break, it's like (well, is) a global error flag > --- but the error status gets reset at the top level command loop, > which we reach in a script after the end of a set of complex commands > --- but only right at the end, when we're reading a new (possibly > complex, arbitrarily nested) command from the script. > > I think actually what's going on could be considered a bug which is an > oversight for the case of scripts. Hmmm... there are multiple loops here and they have different error handling. In loop(), if (((!interact || sourcelevel) && errflag) || retflag) break; This actually does what I want: if it's not interactive, and there's an error, break out of the loop. This is the "top level" loop I was thinking of. However, there are two even topper level loops in zsh_main(). They appear to be limited to handling the case of hitting EOF and a parse error --- no other sort of error --- however, and aren't restricted to interactive behaviour. I don't really like the look of the combination of these three loops --- it smells to me like the effect hasn't been thought through properly. I can see you need to exit if you've got a parse error, because you don't know what to execute yet, but I don't see that you need to ignore all other errors in the outer loops. retflag and sourcelevel are irrelevant out here but I can definitely see a case for "if (!interact && errflag) /* exit */". pws ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-05 14:55 ` Peter Stephenson @ 2012-11-05 16:08 ` Peter Stephenson 2012-11-06 6:47 ` Han Pingtian 2012-11-09 22:52 ` Peter Stephenson 1 sibling, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2012-11-05 16:08 UTC (permalink / raw) To: zsh-workers Another inconsistency with error handling... % fn() { setopt mumbly; print Got here; } % fn fn:setopt: no such option: mumbly Got here % fn() { set -o mumbly; print Got here; } % fn fn:set: no such option: mumbly This is because set is a POSIX special builtin but setopt isn't. It should be documented, however. Index: Doc/Zsh/builtins.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/builtins.yo,v retrieving revision 1.145 diff -p -u -r1.145 builtins.yo --- Doc/Zsh/builtins.yo 11 Oct 2012 20:14:03 -0000 1.145 +++ Doc/Zsh/builtins.yo 5 Nov 2012 16:06:10 -0000 @@ -1361,6 +1361,11 @@ or without the tt(no) prefix remains the If the tt(-m) flag is given the arguments are taken as patterns (which should be quoted to protect them from filename expansion), and all options with names matching these patterns are set. + +Note that a bad option name does not cause execution of shell code +to be aborted; this is different from `tt(set -o)'. This is because +tt(set) is regarded as a special builtin by the POSIX standard, +but tt(setopt) is not. ) findex(shift) cindex(parameters, positional) pws ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-05 16:08 ` Peter Stephenson @ 2012-11-06 6:47 ` Han Pingtian 0 siblings, 0 replies; 12+ messages in thread From: Han Pingtian @ 2012-11-06 6:47 UTC (permalink / raw) To: zsh-workers This looks like also a inconsistency (or I'm missing something again): Though both 'print nosuchfile*' and 'ls nosuchfile*' return non-zero vaules, but the internal command one won't trigger ZERR trap, but the external one does: #!/usr/local/bin/zsh -feu trap 'echo caught a error' ZERR ls nosuchfile* will fail with ./t3.sh:5: no matches found: nosuchfile* caught a error but this one #!/usr/local/bin/zsh -feu trap 'echo caught a error' ZERR print nosuchfile* will fail only with ./t3.sh:5: no matches found: nosuchfile* ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-05 14:55 ` Peter Stephenson 2012-11-05 16:08 ` Peter Stephenson @ 2012-11-09 22:52 ` Peter Stephenson 2012-11-10 1:13 ` Bart Schaefer 1 sibling, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2012-11-09 22:52 UTC (permalink / raw) To: zsh-workers On the behaviour that when the shell encounters a "fatal" error in a script it resumes at the next "top level" command: here's a proposal. This makes that behaviour optional, for compatibility, but turns it off by default. I don't think the old, undocumented, behaviour is intuitive enough for us to go on leaving it as the default. The shell essentially skips a chunk of code and resumes later on at a point where there's not the slightest reason to suppose it's appropriate to do so; you might be relying on the structure that was previously executing to set things up for the next chunk of code. I'm not really even sure we need the option, but it seems possible that people who happened on the behaviour have become reliant on it. I've taken the opportunity to document the behaviour on fatal errors. The list is exhausting rather than exhaustive. I haven't bothered listing errors associated with interactive shells where you'd be returned to the command prompt. That test at the end was a bit weird: I don't think it was testing POSIX_BUILTINS at all since errors with read-only variables are always hard errors as a grep for the error message will immediately show. It does provide a useful test for CONTINUE_ON_ERROR. Index: Doc/Zsh/grammar.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/grammar.yo,v retrieving revision 1.23 diff -p -u -r1.23 grammar.yo --- Doc/Zsh/grammar.yo 1 Feb 2012 12:53:49 -0000 1.23 +++ Doc/Zsh/grammar.yo 9 Nov 2012 22:43:30 -0000 @@ -438,7 +438,7 @@ where var(term) is at least one newline A short form of tt(select). ) enditem() -texinode(Reserved Words)(Comments)(Alternate Forms For Complex Commands)(Shell Grammar) +texinode(Reserved Words)(Errors)(Alternate Forms For Complex Commands)(Shell Grammar) sect(Reserved Words) cindex(reserved words) findex(disable, use of) @@ -451,7 +451,56 @@ select coproc nocorrect foreach end ! [[ Additionally, `tt(})' is recognized in any position if neither the tt(IGNORE_BRACES) option nor the tt(IGNORE_CLOSE_BRACES) option is set. -texinode(Comments)(Aliasing)(Reserved Words)(Shell Grammar) +texinode(Errors)(Comments)(Reserved Words)(Shell Grammar) +sect(Errors) +cindex(errors, handling of) +Certain errors are treated as fatal by the shell: in an interactive +shell, they cause control to return to the command line, and in a +non-interactive shell they cause the shell to be aborted. In older +versions of zsh, a non-interactive shell running a script would not +abort completely, but would resume execution at the next command to be +read from the script, skipping the remainder of any functions or +shell constructs such as loops or conditions; this somewhat illogical +behaviour can be recovered by setting the option tt(CONTINUE_ON_ERROR). + +Fatal errors found in non-interactive shells include: +startlist() +list(Failure to parse shell options passed when invoking the shell) +list(Failure to change options with the tt(set) builtin) +list(Parse errors of all sorts, including failures to parse +mathematical expressions) +list(Failures to set or modify variable behaviour with tt(typeset), +tt(local), tt(declare), tt(export), tt(integer), tt(float)) +list(Execution of incorrectly positioned loop control structures +(tt(continue), tt(break))) +list(Attempts to use regular expression with no regular expression +module available) +list(Disallowed operations when the tt(RESTRICTED) options is set) +list(Failure to create a pipe needed for a pipeline) +list(Failure to create a multio) +list(Failure to autoload a module needed for a declared shell feature) +list(Errors creating command or process substitutions) +list(Syntax errors in glob qualifiers) +list(File generation errors where not caught by the option tt(BAD_PATTERN)) +list(All bad patterns used for matching within case statements) +list(File generation failures where not caused by tt(NO_MATCH) or +list(All file generation errors where the pattern was used to create a +multio) +list(Memory errors where detected by the shell) +list(Invalid subscripts to shell variables) +list(Attempts to assign read-only variables) +list(Logical errors with variables such as assignment to the wrong type) +list(Use of invalid variable names) +list(Errors in variable substitution syntax) +list(Failure to convert characters in tt($')...tt(') expressions) +similar options) +endlist() + +If the tt(POSIX_BUILTINS) option is set, more errors associated with +shell builtin commands are treated as fatal, as specified by the POSIX +standard. + +texinode(Comments)(Aliasing)(Errors)(Shell Grammar) sect(Comments) cindex(comments) pindex(INTERACTIVE_COMMENTS, use of) Index: Doc/Zsh/options.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v retrieving revision 1.107 diff -p -u -r1.107 options.yo --- Doc/Zsh/options.yo 1 Mar 2012 03:34:15 -0000 1.107 +++ Doc/Zsh/options.yo 9 Nov 2012 22:43:31 -0000 @@ -1733,6 +1733,22 @@ Make the tt(echo) builtin compatible wit This disables backslashed escape sequences in echo strings unless the tt(-e) option is specified. ) +pindex(CONTINUE_ON_ERROR) +pindex(NO_CONTINUE_ON_ERROR) +pindex(CONTINUEONERROR) +pindex(NOCONTINUEONERROR) +cindex(error, option to continue script on) +item(tt(CONTINUE_ON_ERROR))( +If a fatal error is encountered (see +ifnzman(noderef(Errors))\ +ifzman(the section ERRORS in zmanref(zshmisc))), and the code is running +in a script, the shell will resume execution at the next statement +in the script at the top level, in other words outside all functions +or shell constructs such as loops and conditions. This mimics the +behaviour of interactive shells, where the shell returns to the +line editor to read a new command; it was the normal behaviour in versions +of zsh before 5.0.1. +) pindex(CSH_JUNKIE_HISTORY) pindex(NO_CSH_JUNKIE_HISTORY) pindex(CSHJUNKIEHISTORY) Index: Src/hist.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/hist.c,v retrieving revision 1.118 diff -p -u -r1.118 hist.c --- Src/hist.c 21 Apr 2012 18:42:56 -0000 1.118 +++ Src/hist.c 9 Nov 2012 22:43:31 -0000 @@ -573,7 +573,7 @@ histsubchar(int c) } else { herrflush(); unqueue_signals(); - zerr("Ambiguous history reference"); + zerr("ambiguous history reference"); return -1; } Index: Src/init.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/init.c,v retrieving revision 1.127 diff -p -u -r1.127 init.c --- Src/init.c 11 Oct 2012 20:14:03 -0000 1.127 +++ Src/init.c 9 Nov 2012 22:43:31 -0000 @@ -1608,15 +1608,20 @@ zsh_main(UNUSED(int argc), char **argv) * We only do this at top level, because if we are * executing stuff we may refer to them by job pointer. */ + int errexit = 0; maybeshrinkjobtab(); do { /* Reset return from top level which gets us back here */ retflag = 0; loop(1,0); + if (errflag && !interact && !isset(CONTINUEONERROR)) { + errexit = 1; + break; + } } while (tok != ENDINPUT && (tok != LEXERR || isset(SHINSTDIN))); - if (tok == LEXERR) { - /* Make sure a parse error exits with non-zero status */ + if (tok == LEXERR || errexit) { + /* Make sure a fatal error exits with non-zero status */ if (!lastval) lastval = 1; stopmsg = 1; Index: Src/options.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/options.c,v retrieving revision 1.65 diff -p -u -r1.65 options.c --- Src/options.c 11 Oct 2012 20:14:03 -0000 1.65 +++ Src/options.c 9 Nov 2012 22:43:31 -0000 @@ -113,6 +113,7 @@ static struct optname optns[] = { {{NULL, "combiningchars", 0}, COMBININGCHARS}, {{NULL, "completealiases", 0}, COMPLETEALIASES}, {{NULL, "completeinword", 0}, COMPLETEINWORD}, +{{NULL, "continueonerror", 0}, CONTINUEONERROR}, {{NULL, "correct", 0}, CORRECT}, {{NULL, "correctall", 0}, CORRECTALL}, {{NULL, "cshjunkiehistory", OPT_EMULATE|OPT_CSH}, CSHJUNKIEHISTORY}, Index: Src/zsh.h =================================================================== RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v retrieving revision 1.186 diff -p -u -r1.186 zsh.h --- Src/zsh.h 11 Oct 2012 20:14:03 -0000 1.186 +++ Src/zsh.h 9 Nov 2012 22:43:31 -0000 @@ -1971,6 +1971,7 @@ enum { COMPLETEINWORD, CORRECT, CORRECTALL, + CONTINUEONERROR, CPRECEDENCES, CSHJUNKIEHISTORY, CSHJUNKIELOOPS, Index: Test/A04redirect.ztst =================================================================== RCS file: /cvsroot/zsh/zsh/Test/A04redirect.ztst,v retrieving revision 1.24 diff -p -u -r1.24 A04redirect.ztst --- Test/A04redirect.ztst 3 Oct 2012 18:11:15 -0000 1.24 +++ Test/A04redirect.ztst 9 Nov 2012 22:43:31 -0000 @@ -419,26 +419,26 @@ >output ?zsh:.:2: no such file or directory: /nonexistent/nonexistent - $ZTST_testdir/../Src/zsh -f <<<' + $ZTST_testdir/../Src/zsh -f -o CONTINUE_ON_ERROR <<<' readonly foo foo=bar set output echo output' -0:failed assignment on posix special, NO_POSIX_BUILTINS +0:failed assignment on posix special, CONTINUE_ON_ERROR >output ?zsh: read-only variable: foo - $ZTST_testdir/../Src/zsh -f -o POSIX_BUILTINS <<<' + $ZTST_testdir/../Src/zsh -f <<<' readonly foo foo=bar set output echo output' -1:failed assignment on posix special, POSIX_BUILTINS +1:failed assignment on posix special, NO_CONTINUE_ON_ERROR ?zsh: read-only variable: foo - $ZTST_testdir/../Src/zsh -f -o POSIX_BUILTINS <<<' + $ZTST_testdir/../Src/zsh -f -o CONTINUE_ON_ERROR <<<' readonly foo foo=bar echo output echo output' -0:failed assignment on non-posix-special, POSIX_BUILTINS +0:failed assignment on non-posix-special, CONTINUE_ON_ERROR >output ?zsh: read-only variable: foo -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-09 22:52 ` Peter Stephenson @ 2012-11-10 1:13 ` Bart Schaefer 2012-11-10 21:23 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2012-11-10 1:13 UTC (permalink / raw) To: zsh-workers On Nov 9, 10:52pm, Peter Stephenson wrote: } } On the behaviour that when the shell encounters a "fatal" error in a } script it resumes at the next "top level" command: here's a proposal. } This makes that behaviour optional, for compatibility, but turns it off } by default. I don't think the old, undocumented, behaviour is intuitive } enough for us to go on leaving it as the default. The shell essentially } skips a chunk of code and resumes later on at a point where there's not } the slightest reason to suppose it's appropriate to do so; you might be } relying on the structure that was previously executing to set things up } for the next chunk of code. I believe I know the reason for this behavior, and perhaps it points to a bug: When reading a startup file such as .zshrc, there is an intent to avoid skipping the entire configuration just because of one erroneous command somewhere in the middle. My possibly flawed recollection was that this was only supposed to happen in startup scripts, not in scripts run as standalone programs or loaded by "source" or ".". If this patch modifies the behavior of startup files, perhaps one further step would be to turn on CONTINUE_ON_ERROR before startup files are read, then turn it off before entering the main loop iff the starup files themselves have not frobbed it. I believe something similar is done with MONITOR and also HASHDIRS. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-10 1:13 ` Bart Schaefer @ 2012-11-10 21:23 ` Peter Stephenson 2012-11-12 10:24 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2012-11-10 21:23 UTC (permalink / raw) To: zsh-workers On Fri, 09 Nov 2012 17:13:19 -0800 Bart Schaefer <schaefer@brasslantern.com> wrote: > I believe I know the reason for this behavior, and perhaps it points to a > bug: > > When reading a startup file such as .zshrc, there is an intent to avoid > skipping the entire configuration just because of one erroneous command > somewhere in the middle. I've a vague memory of this too, but evidence suggests it's not showing CONTINUE_ON_ERROR behaviour (this is before my patch): % cat ~/tmp/zdotdir/.zshrc print First line echo *fumblewumble* print Second line % ZDOTDIR=~/tmp/zdotdir zsh First line /home/pws/tmp/zdotdir/.zshrc:2: no matches found: *fumblewumble* % exit # <- this is the prompt inside the new shell % zsh ~/tmp/zdotdir/.zshrc First line /home/pws/tmp/zdotdir/.zshrc:2: no matches found: *fumblewumble* Second line So if that was the intention, we've already messed it up. A bit of historical research might be interesting. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Function code breaking out of if then ...fi 2012-11-10 21:23 ` Peter Stephenson @ 2012-11-12 10:24 ` Peter Stephenson 0 siblings, 0 replies; 12+ messages in thread From: Peter Stephenson @ 2012-11-12 10:24 UTC (permalink / raw) To: zsh-workers On Sat, 10 Nov 2012 21:23:30 +0000 Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > On Fri, 09 Nov 2012 17:13:19 -0800 > Bart Schaefer <schaefer@brasslantern.com> wrote: > > When reading a startup file such as .zshrc, there is an intent to > > avoid skipping the entire configuration just because of one > > erroneous command somewhere in the middle. > > I've a vague memory of this too, but evidence suggests it's not > showing CONTINUE_ON_ERROR behaviour (this is before my patch): In fact, the code I've altered can't have an effect on this: as it says in the essay I wrote before, I'm modifying code above the "top-level" loop in loop(), that's called mainly to handle "do you really want to exit" for interactive shells. The initialisation code is not handled from here; run_init_scripts() has finised from this point. I think we'd need code within loop() itself, which handles the lines read from startup files. In this code the test if (((!interact || sourcelevel) && errflag) || retflag) break; ensures we *do* break out of the loop if we're sourcing a file (whether or not at initialisation). Hmm... we're not getting confused between keeping going in a particular startup file and allowing the shell to execute another file, are we? pws ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-11-12 10:34 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-11-02 9:09 Function code breaking out of if then ...fi Michal Maruska 2012-11-02 21:39 ` Bart Schaefer 2012-11-05 8:22 ` Han Pingtian 2012-11-05 9:31 ` Han Pingtian 2012-11-05 14:29 ` Peter Stephenson 2012-11-05 14:55 ` Peter Stephenson 2012-11-05 16:08 ` Peter Stephenson 2012-11-06 6:47 ` Han Pingtian 2012-11-09 22:52 ` Peter Stephenson 2012-11-10 1:13 ` Bart Schaefer 2012-11-10 21:23 ` Peter Stephenson 2012-11-12 10:24 ` Peter Stephenson
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).