* Weird exit caused in a trap DEBUG which sources a file. @ 2008-07-31 2:38 Rocky Bernstein 2008-07-31 9:01 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Rocky Bernstein @ 2008-07-31 2:38 UTC (permalink / raw) To: zsh-workers Below is a small program whittled down from a larger one. It has behavior I can't figure out. It seems to show that when a function is called via trap DEBUG and you then source a file and it has a statement in it, on return from the TRAP an exit will be taken. Here is the program: #!/usr/bin/zsh function debug_trap_handler { print $functrace[1] do_bug } function do_bug { . ./bug-file } trap 'echo EXIT hit' EXIT trap 'debug_trap_handler' DEBUG a=1 b=2 d=3 In "bug-file" put any command. ":" will do. Or a print statement. Let's say it contains the line: print bug file here When I run the above I get: $ ./zshtrace.sh ./zshtrace.sh:12 bug file here EXIT hit Now if the file contains only comments or blank lines or is empty, here is what I get: $ ./zshtrace.sh ./zshtrace.sh:12 ./zshtrace.sh:13 ./zshtrace.sh:14 ./zshtrace.sh:15 EXIT hit which is what I would expect. Anyone care to venture a guess as to what's going on? It feels like a bug to me, if for no other reason than some message about why the exit was raised is missing. Thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Weird exit caused in a trap DEBUG which sources a file. 2008-07-31 2:38 Weird exit caused in a trap DEBUG which sources a file Rocky Bernstein @ 2008-07-31 9:01 ` Peter Stephenson 2008-07-31 10:05 ` Rocky Bernstein 0 siblings, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2008-07-31 9:01 UTC (permalink / raw) To: zsh-workers "Rocky Bernstein" wrote: > Below is a small program whittled down from a larger one. It has > behavior I can't figure out. > > It seems to show that when a function is called via trap DEBUG and you > then source a file and it has a statement in it, on return from the > TRAP an exit will be taken. Here is the program: > > #!/usr/bin/zsh > function debug_trap_handler { > print $functrace[1] > do_bug > } > > function do_bug { > . ./bug-file > } > > trap 'echo EXIT hit' EXIT > trap 'debug_trap_handler' DEBUG > a=1 > b=2 > d=3 > > In "bug-file" put any command. ":" will do. Or a print statement. > Let's say it contains the line: > print bug file here > > When I run the above I get: > > $ ./zshtrace.sh > > ./zshtrace.sh:12 > bug file here > EXIT hit That certainly looks like a bug, but it didn't happen for me. What version of the shell do you have, and does it happen with the -f option after /usr/bin/zsh? -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Weird exit caused in a trap DEBUG which sources a file. 2008-07-31 9:01 ` Peter Stephenson @ 2008-07-31 10:05 ` Rocky Bernstein 2008-08-01 12:29 ` Rocky Bernstein 0 siblings, 1 reply; 12+ messages in thread From: Rocky Bernstein @ 2008-07-31 10:05 UTC (permalink / raw) To: zsh-workers I don't get different results by adding -f. However I do get different results depending on the zsh version. The buggy output was run using the stock zsh for Ubunty Hardy Heron: zsh 4.3.4 (i686-pc-linux-gnu) I don't get it for the "zsh-beta" package which is zsh 4.3.5-dev-0+ (i686-pc-linux-gnu) Life would be good were that were the end of the story. This is this is whittled down from a larger set of files, and in that larger set, I still have the problem no matter which of the above two zsh's is used or a third or the one I built from recent CVS with the patches I posted applied. So it looks like I'll have to go back and start again from the larger program and whittle it down again. If anyone is aware of what bug was fixed between 4.3.4 and 4.3.5-dev-0 that addresses this, it might help understand the nature of the problem better. (I will also at some point scour ChangeLogs to try to figure this out too.) Thanks for double checking and the suggestions. On Thu, Jul 31, 2008 at 5:01 AM, Peter Stephenson <pws@csr.com> wrote: > "Rocky Bernstein" wrote: >> Below is a small program whittled down from a larger one. It has >> behavior I can't figure out. >> >> It seems to show that when a function is called via trap DEBUG and you >> then source a file and it has a statement in it, on return from the >> TRAP an exit will be taken. Here is the program: >> >> #!/usr/bin/zsh >> function debug_trap_handler { >> print $functrace[1] >> do_bug >> } >> >> function do_bug { >> . ./bug-file >> } >> >> trap 'echo EXIT hit' EXIT >> trap 'debug_trap_handler' DEBUG >> a=1 >> b=2 >> d=3 >> >> In "bug-file" put any command. ":" will do. Or a print statement. >> Let's say it contains the line: >> print bug file here >> >> When I run the above I get: >> >> $ ./zshtrace.sh >> >> ./zshtrace.sh:12 >> bug file here >> EXIT hit > > That certainly looks like a bug, but it didn't happen for me. What > version of the shell do you have, and does it happen with the -f option > after /usr/bin/zsh? > > -- > Peter Stephenson <pws@csr.com> Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Weird exit caused in a trap DEBUG which sources a file. 2008-07-31 10:05 ` Rocky Bernstein @ 2008-08-01 12:29 ` Rocky Bernstein 2008-08-01 13:37 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Rocky Bernstein @ 2008-08-01 12:29 UTC (permalink / raw) To: zsh-workers Looks like the crucial change that makes zsh 4.3.5-dev and current SVN sources fail is an extra source after the trap DEBUG: #!/bin/zsh-beta -f function debug_trap_handler { print $functrace[1] . ./bug-file } trap 'echo EXIT hit' EXIT trap 'debug_trap_handler' DEBUG . ./testing.sh Put in ./testing.sh and bug-file some executable code. You probably want to have several statements in testing.sh so you can see exiting after the first statement. On Thu, Jul 31, 2008 at 6:05 AM, Rocky Bernstein <rocky.bernstein@gmail.com> wrote: > I don't get different results by adding -f. However I do get different > results depending on the zsh version. > > The buggy output was run using the stock zsh for Ubunty Hardy Heron: > zsh 4.3.4 (i686-pc-linux-gnu) > > I don't get it for the "zsh-beta" package which is > zsh 4.3.5-dev-0+ (i686-pc-linux-gnu) > > Life would be good were that were the end of the story. > > This is this is whittled down from a larger set of files, and in that > larger set, I still have the problem no matter which of the above two > zsh's is used or a third or the one I built from recent CVS with the > patches I posted applied. So it looks like I'll have to go back and > start again from the larger program and whittle it down again. > > If anyone is aware of what bug was fixed between 4.3.4 and 4.3.5-dev-0 > that addresses this, it might help understand the nature of the > problem better. (I will also at some point scour ChangeLogs to try to > figure this out too.) > > Thanks for double checking and the suggestions. > > > On Thu, Jul 31, 2008 at 5:01 AM, Peter Stephenson <pws@csr.com> wrote: >> "Rocky Bernstein" wrote: >>> Below is a small program whittled down from a larger one. It has >>> behavior I can't figure out. >>> >>> It seems to show that when a function is called via trap DEBUG and you >>> then source a file and it has a statement in it, on return from the >>> TRAP an exit will be taken. Here is the program: >>> >>> #!/usr/bin/zsh >>> function debug_trap_handler { >>> print $functrace[1] >>> do_bug >>> } >>> >>> function do_bug { >>> . ./bug-file >>> } >>> >>> trap 'echo EXIT hit' EXIT >>> trap 'debug_trap_handler' DEBUG >>> a=1 >>> b=2 >>> d=3 >>> >>> In "bug-file" put any command. ":" will do. Or a print statement. >>> Let's say it contains the line: >>> print bug file here >>> >>> When I run the above I get: >>> >>> $ ./zshtrace.sh >>> >>> ./zshtrace.sh:12 >>> bug file here >>> EXIT hit >> >> That certainly looks like a bug, but it didn't happen for me. What >> version of the shell do you have, and does it happen with the -f option >> after /usr/bin/zsh? >> >> -- >> Peter Stephenson <pws@csr.com> Software Engineer >> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road >> Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Weird exit caused in a trap DEBUG which sources a file. 2008-08-01 12:29 ` Rocky Bernstein @ 2008-08-01 13:37 ` Peter Stephenson 2008-08-01 15:21 ` Rocky Bernstein 0 siblings, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2008-08-01 13:37 UTC (permalink / raw) To: zsh-workers On Fri, 1 Aug 2008 08:29:29 -0400 "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote: > Looks like the crucial change that makes zsh 4.3.5-dev and current SVN > sources fail is an extra source after the trap DEBUG: Thanks, this is what I needed. The source code wasn't handling the variable that indicates a trap has told us to return from a function properly. The variable is only primed for action if negative. That's the init.c hunk. The signals.c hunk is to save and restore trapreturn for nested trap handlers. I'm not sure it's necessary; I am sure it's not wrong and prevents hostages to fortune. The hairy trap tests still pass, which is good; it would be better to add this as a test, too, which shouldn't be too hard as there's nothing here that depends on external behaviour. I've documented the variable trapreturn better. Index: Src/exec.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/exec.c,v retrieving revision 1.135 diff -u -r1.135 exec.c --- Src/exec.c 31 Jul 2008 08:44:21 -0000 1.135 +++ Src/exec.c 1 Aug 2008 13:29:06 -0000 @@ -64,7 +64,23 @@ /**/ mod_export int errflag; -/* Status of return from a trap */ +/* + * Status of return from a trap. + * This is only active if we are inside a trap, else its value + * is irrelevant. It is initialised to -1 for a function trap and + * -2 for a non-function trap and if negative is decremented as + * we go deeper into functions and incremented as we come back up. + * The value is used to decide if an explicit "return" should cause + * a return from the caller of the trap; it does this by setting + * trapreturn to a status (i.e. a non-negative value). + * + * In summary, trapreturn is + * - zero unless we are in a trap + * - negative in a trap unless it has triggered. Code uses this + * to detect an active trap. + * - non-negative in a trap once it was triggered. It should remain + * non-negative until restored after execution of the trap. + */ /**/ int trapreturn; Index: Src/init.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/init.c,v retrieving revision 1.87 diff -u -r1.87 init.c --- Src/init.c 31 Jul 2008 08:44:21 -0000 1.87 +++ Src/init.c 1 Aug 2008 13:29:06 -0000 @@ -191,7 +191,7 @@ exit(lastval); if (((!interact || sourcelevel) && errflag) || retflag) break; - if (trapreturn) { + if (trapreturn >= 0) { lastval = trapreturn; trapreturn = 0; } Index: Src/signals.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/signals.c,v retrieving revision 1.47 diff -u -r1.47 signals.c --- Src/signals.c 31 Jul 2008 08:44:21 -0000 1.47 +++ Src/signals.c 1 Aug 2008 13:29:06 -0000 @@ -1085,6 +1085,7 @@ int trapret = 0; int obreaks = breaks; int oretflag = retflag; + int otrapreturn = trapreturn; int isfunc; int traperr; @@ -1183,6 +1184,7 @@ trapret = trapreturn + 1; } traperr = errflag; + trapreturn = otrapreturn; execrestore(); lexrestore(); -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Weird exit caused in a trap DEBUG which sources a file. 2008-08-01 13:37 ` Peter Stephenson @ 2008-08-01 15:21 ` Rocky Bernstein 2008-08-01 15:31 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Rocky Bernstein @ 2008-08-01 15:21 UTC (permalink / raw) To: zsh-workers Comments in line. On Fri, Aug 1, 2008 at 9:37 AM, Peter Stephenson <pws@csr.com> wrote: > On Fri, 1 Aug 2008 08:29:29 -0400 > "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote: >> Looks like the crucial change that makes zsh 4.3.5-dev and current SVN >> sources fail is an extra source after the trap DEBUG: > > Thanks, this is what I needed. No, thank you! I just tried the patch and it works fine. So there's no mystery. I've been porting the bash debugger code to zsh. So far, print/eval, stepping and some stack frame commands work. But this is far from ready for general consumption. Part of this is a more general effort at writing about POSIX shells which I give maybe a 50% chance of happening. > > The source code wasn't handling the variable that indicates a trap has told > us to return from a function properly. The variable is only primed for > action if negative. That's the init.c hunk. > > The signals.c hunk is to save and restore trapreturn for nested trap > handlers. I'm not sure it's necessary; I am sure it's not wrong and > prevents hostages to fortune. Not sure the additional code is necessary or that nested trap handlers are necessary? I'm pretty sure you mean the former. Nested trap handlers are useful. > > The hairy trap tests still pass, which is good; it would be better to add > this as a test, too, which shouldn't be too hard as there's nothing here > that depends on external behaviour. > > I've documented the variable trapreturn better. Thanks. It seems weird that trapreturn is is initialised to -1 for a function trap and -2 for a non-function trap and decremented for subsequent function calls. Because this means that trapreturn for a for a function trap that calls a function would have the same value as for a non-function trap. > > Index: Src/exec.c > =================================================================== > RCS file: /cvsroot/zsh/zsh/Src/exec.c,v > retrieving revision 1.135 > diff -u -r1.135 exec.c > --- Src/exec.c 31 Jul 2008 08:44:21 -0000 1.135 > +++ Src/exec.c 1 Aug 2008 13:29:06 -0000 > @@ -64,7 +64,23 @@ > /**/ > mod_export int errflag; > > -/* Status of return from a trap */ > +/* > + * Status of return from a trap. > + * This is only active if we are inside a trap, else its value > + * is irrelevant. It is initialised to -1 for a function trap and > + * -2 for a non-function trap and if negative is decremented as > + * we go deeper into functions and incremented as we come back up. > + * The value is used to decide if an explicit "return" should cause > + * a return from the caller of the trap; it does this by setting > + * trapreturn to a status (i.e. a non-negative value). > + * > + * In summary, trapreturn is > + * - zero unless we are in a trap > + * - negative in a trap unless it has triggered. Code uses this > + * to detect an active trap. > + * - non-negative in a trap once it was triggered. It should remain > + * non-negative until restored after execution of the trap. > + */ > > /**/ > int trapreturn; > Index: Src/init.c > =================================================================== > RCS file: /cvsroot/zsh/zsh/Src/init.c,v > retrieving revision 1.87 > diff -u -r1.87 init.c > --- Src/init.c 31 Jul 2008 08:44:21 -0000 1.87 > +++ Src/init.c 1 Aug 2008 13:29:06 -0000 > @@ -191,7 +191,7 @@ > exit(lastval); > if (((!interact || sourcelevel) && errflag) || retflag) > break; > - if (trapreturn) { > + if (trapreturn >= 0) { > lastval = trapreturn; > trapreturn = 0; > } > Index: Src/signals.c > =================================================================== > RCS file: /cvsroot/zsh/zsh/Src/signals.c,v > retrieving revision 1.47 > diff -u -r1.47 signals.c > --- Src/signals.c 31 Jul 2008 08:44:21 -0000 1.47 > +++ Src/signals.c 1 Aug 2008 13:29:06 -0000 > @@ -1085,6 +1085,7 @@ > int trapret = 0; > int obreaks = breaks; > int oretflag = retflag; > + int otrapreturn = trapreturn; > int isfunc; > int traperr; > > @@ -1183,6 +1184,7 @@ > trapret = trapreturn + 1; > } > traperr = errflag; > + trapreturn = otrapreturn; > execrestore(); > lexrestore(); > > > -- > Peter Stephenson <pws@csr.com> Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Weird exit caused in a trap DEBUG which sources a file. 2008-08-01 15:21 ` Rocky Bernstein @ 2008-08-01 15:31 ` Peter Stephenson 2008-08-02 11:21 ` Rocky Bernstein 0 siblings, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2008-08-01 15:31 UTC (permalink / raw) To: Rocky Bernstein; +Cc: zsh-workers "Rocky Bernstein" wrote: > On Fri, Aug 1, 2008 at 9:37 AM, Peter Stephenson <pws@csr.com> wrote: > > Thanks, this is what I needed. > > No, thank you! I just tried the patch and it works fine. Good. > So there's no mystery. I've been porting the bash debugger code to > zsh. So far, print/eval, stepping and some stack frame commands work. > But this is far from ready for general consumption. This will be very useful. > > The signals.c hunk is to save and restore trapreturn for nested trap > > handlers. I'm not sure it's necessary; I am sure it's not wrong and > > prevents hostages to fortune. > > Not sure the additional code is necessary or that nested trap handlers > are necessary? I'm pretty sure you mean the former. Nested trap > handlers are useful. Yes, I'm talking about the additional code. I think it probably *is* necessary for consistency, but there are cases where we disable nested handling (so for example we don't run a DEBUG trap on commands when we're inside a DEBUG trap). > It seems weird that trapreturn is is initialised to -1 for a > function trap and > -2 for a non-function trap and decremented for subsequent function > calls. Because this means that trapreturn for a for a function trap > that calls a function would have the same value as for a non-function > trap. This is because of the way an explicit "return" from a trap works (which is documented in the manual). "return" with non-zero status from a shell function forces the parent function to return; "return" with any status from a non-function trap forces the immediately surrounding function to return. In other words, the difference is there's an extra level of functions in one case which we have to jump over for the special return. -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Weird exit caused in a trap DEBUG which sources a file. 2008-08-01 15:31 ` Peter Stephenson @ 2008-08-02 11:21 ` Rocky Bernstein 2008-08-03 10:42 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Rocky Bernstein @ 2008-08-02 11:21 UTC (permalink / raw) To: zsh-workers Hmm. This brings up a couple of other things to consider. It may be useful to have some "trap DEBUG" exit codes alter program flow. For example in bash if "trap DEBUG" returns 2, then if you are inside a function that does an immediate return from the function (implementing a gdb "return" command). It might also be nice to have a "trap DEBUG" exit value which indicates that the next command is skipped rather than executed. Of course, this makes more sense when "trap DEBUG" is run before a statement is executed rather than after, because doing these things when you don't really know what the next statement is or which function you are in is like flying blind. And since I brought up "trap DEBUG" execution order again, at the risk of beating a dead horse... I recently asked David Korn about this: me: I guess what I was asking is why it originally kicked in afterwards rather than before. This one seemingly innocuous thing is one of the biggest things that kept writing a serious debugger impossible. (But of course as perhaps you may understand, there are others that still make it hard.) David Korn: That was a mistake which is why I changed it. I also recall suggesting to Chet Ramey that another trap could be added like "trap DEBUG" if compatibility was at issue. Although I never got a reply, he too didn't try to keep the previous behavior which suggests, like David Korn, he thought it just wrong. In neither case am I aware of any outcry of incompatibility because this behavior was changed. On Fri, Aug 1, 2008 at 11:31 AM, Peter Stephenson <pws@csr.com> wrote: > > This is because of the way an explicit "return" from a trap works (which > is documented in the manual). "return" with non-zero status from a > shell function forces the parent function to return; "return" with any > status from a non-function trap forces the immediately surrounding > function to return. In other words, the difference is there's an extra > level of functions in one case which we have to jump over for the > special return. > > -- > Peter Stephenson <pws@csr.com> Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Weird exit caused in a trap DEBUG which sources a file. 2008-08-02 11:21 ` Rocky Bernstein @ 2008-08-03 10:42 ` Peter Stephenson 2008-08-03 11:28 ` Rocky Bernstein 0 siblings, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2008-08-03 10:42 UTC (permalink / raw) To: zsh-workers On Sat, 2 Aug 2008 07:21:43 -0400 "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote: > > It may be useful to have some "trap DEBUG" exit codes alter program > flow. For example in bash if "trap DEBUG" returns 2, then if you are > inside a function that does an immediate return from the function > (implementing a gdb "return" command). This happens on any explicit "return" from a non-function trap. > It might also be nice to have a "trap DEBUG" exit value which > indicates that the next command is skipped rather than executed. That's a little more tricky: it's not very clear what the next command actually is if it's a complicated expression. Looking at the code, it's not hard to do something here, but making it properly consistent is another matter. I think it would probably work if done at the level of commands separated by semicolons, newlines or ampersands (described internally as sublists). > And since I brought up "trap DEBUG" execution order again, at the risk > of beating a dead horse... I don't really understand what the issue is. Is there something about the DEBUG_BEFORE_CMD option that makes it hard to ensure it is set at the right point (this is not a trick question, that's perfectly possible)? -- 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: Weird exit caused in a trap DEBUG which sources a file. 2008-08-03 10:42 ` Peter Stephenson @ 2008-08-03 11:28 ` Rocky Bernstein 2008-08-03 11:50 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Rocky Bernstein @ 2008-08-03 11:28 UTC (permalink / raw) To: zsh-workers Comments in line. On Sun, Aug 3, 2008 at 6:42 AM, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > On Sat, 2 Aug 2008 07:21:43 -0400 > "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote: >> >> It may be useful to have some "trap DEBUG" exit codes alter program >> flow. For example in bash if "trap DEBUG" returns 2, then if you are >> inside a function that does an immediate return from the function >> (implementing a gdb "return" command). > > This happens on any explicit "return" from a non-function trap. > >> It might also be nice to have a "trap DEBUG" exit value which >> indicates that the next command is skipped rather than executed. > > That's a little more tricky: it's not very clear what the next command > actually is if it's a complicated expression. Looking at the code, it's > not hard to do something here, but making it properly consistent is > another matter. I think it would probably work if done at the level of > commands separated by semicolons, newlines or ampersands (described > internally as sublists). I do not see why this is semantically complicated when the trap DEBUG occurs before the statement it refers to is run. Can you give a very specific example of something you feel is tricky? > >> And since I brought up "trap DEBUG" execution order again, at the risk >> of beating a dead horse... > > I don't really understand what the issue is. Is there something about > the DEBUG_BEFORE_CMD option that makes it hard to ensure it is set at > the right point (this is not a trick question, that's perfectly > possible)? David Korn made a mistake and he says so. Chet Ramey also says he changed the behavior because he thought it a mistake too. zsh copied the mistake. The only claim I've heard for keeping the mistake is compatibility with previous versions of zsh. However right now there is no evidence that anyone is making use of this mistake that would not be happier if it weren't made. When this mistake was corrected in bash and ksh, no complaint was registered to keep the old less-helpful behavior. Generally one thinks of the default value as the thing most people would choose. Compatibility is a good thing, but using it as an argument for keeping a mistake that no one is using, seems to me to be blindly following a rule without understanding why the rule is there. So the suggestion is changing the default behavior to something which follows both bash and ksh of the last 6 or so years. If nothing else, both bash and sh emulation in zsh should make this default behavior. Thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Weird exit caused in a trap DEBUG which sources a file. 2008-08-03 11:28 ` Rocky Bernstein @ 2008-08-03 11:50 ` Peter Stephenson 2008-08-05 11:18 ` Rocky Bernstein 0 siblings, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2008-08-03 11:50 UTC (permalink / raw) To: zsh-workers On Sun, 3 Aug 2008 07:28:37 -0400 "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote: > I do not see why this is semantically complicated when the trap DEBUG > occurs before the statement it refers to is run. Can you give a very > specific example of something you feel is tricky? You mean that the new return value from a DEBUG trap should skip everything that would happen until the next trap is run? That's kind of what I ended up saying, and that's well-defined. > David Korn made a mistake and he says so. Chet Ramey also says he > changed the behavior because he thought it a mistake too. zsh copied > the mistake. The only claim I've heard for keeping the mistake is > compatibility with previous versions of zsh. However right now there > is no evidence that anyone is making use of this mistake that would > not be happier if it weren't made. Well, there's no actual evidence it won't cause the toppling of governments in small Himalayan kingdoms, either. We probably won't find out unless we change the default. I agree setting DEBUG_BEFORE_CMD is generally more useful, but you're the only user of the feature I've heard from at all, and I still don't know if there's anything that makes it hard to set the feature explicitly, in either direction (and at least trying to set it in your script is the only way to guarantee the correct behaviour). If you're going to produce a working debugger that requires this to be set then I'll be very tempted to change the default, since a generally available working debugger is extremely useful. Any definite views from anyone else are welcome. -- 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: Weird exit caused in a trap DEBUG which sources a file. 2008-08-03 11:50 ` Peter Stephenson @ 2008-08-05 11:18 ` Rocky Bernstein 0 siblings, 0 replies; 12+ messages in thread From: Rocky Bernstein @ 2008-08-05 11:18 UTC (permalink / raw) To: zsh-workers On Sun, Aug 3, 2008 at 7:50 AM, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > On Sun, 3 Aug 2008 07:28:37 -0400 > "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote: >> I do not see why this is semantically complicated when the trap DEBUG >> occurs before the statement it refers to is run. Can you give a very >> specific example of something you feel is tricky? > > You mean that the new return value from a DEBUG trap should skip > everything that would happen until the next trap is run? Yes. > That's kind of > what I ended up saying, and that's well-defined. Ok. I misunderstood. My mistake. I misremembered bash. The way it currently works is that a return code 1 from a trap causes a skip. See http://bashdb.sourceforge.net/bashdb.html#SEC36 for a description of the debugger command. Right now in bash returning 2 means immediate return. However, it might be slick to have a negative value skip that many levels of return. For a debugger this isn't strictly necessary because the debugger can keep track of the number of levels to return. However for those who write small custom trap DEBUG code (which right now is probably anyone who uses it) it can be a nice convenience. > >> David Korn made a mistake and he says so. Chet Ramey also says he >> changed the behavior because he thought it a mistake too. zsh copied >> the mistake. The only claim I've heard for keeping the mistake is >> compatibility with previous versions of zsh. However right now there >> is no evidence that anyone is making use of this mistake that would >> not be happier if it weren't made. > > Well, there's no actual evidence it won't cause the toppling of > governments in small Himalayan kingdoms, either. We probably won't find > out unless we change the default. I agree setting DEBUG_BEFORE_CMD is > generally more useful, but you're the only user of the feature I've > heard from at all, and I still don't know if there's anything that makes > it hard to set the feature explicitly, in either direction (and at least > trying to set it in your script is the only way to guarantee the correct > behaviour). Well of course right now I do that, because I have to. :-) As for ensuring correct behavior, because the of the dearth of bugs, clearly I'll have to put some tests in to make sure features and bug fixes are there. I've been through this before. I probably won't explicitly test for trap DEBUG but rather may check $ZSH_VERSION. >From my side it would be nice if the debuggers in bash, ksh and zsh shared the same code. But I agree all of this is small stuff. > > If you're going to produce a working debugger that requires this to be > set then I'll be very tempted to change the default, since a generally > available working debugger is extremely useful. There are lots of other useful changes I see happening so if I have a limit, I'd probably want to save that for some of the other things. Probably the next thing on the list is a way to get subshell levels. SHLVL check zsh/bash invocations, but one would like the same thing for subshells. (In bash it is called $BASH_SUBSHELL) I suspect this is pretty straightforward to do. Instead my argument was based on the fact that it's the Right Thing To Do (tm). There are a number of little benefits one gets by doing the right thing. Above I gave one small example. Here are some other small examples: Consider this thread on "How to debug a running process" http://groups.google.com/group/comp.unix.shell/browse_thread/thread/87c3f728476ed29d/5e056069f30efa35 which was written before I was aware of the current zsh behavior. Someone who reads that and decides to do follow will have to know and remember to set the ZSH-specific option to be more useful. RIght now I'm in early stages of writing a book which covers program development in POSIX shell. It will cover trap DEBUG, but I suppose I'd also have to mention the ZSH specific option. Do we want people reminded that this mistake was made and that ZSH makes its presence known by still setting doing this in a less helpful way? "trap DEBUG" is not currently mandated in POSIX 1003.1. However David Korn has said that a number of the features that are common in the POSIX-compatible shells should eventually find their way into some more aggressive spec. Making zsh like bash and ksh will only serve to increase the likelihood that when this happens, trap DEBUG will be there and done in the right way. > > Any definite views from anyone else are welcome. > As before with bash and ksh, resounding silence against and one or two people who've weighed in and said it seems like a good thing. I think it safe to say this is analogous to making the mistake 0/0=1. Many people won't notice or care or feel that strongly about. Personally having been annoyed 3 times by it, so it is irksome to me. Something like 8 years ago, I mentioned it to David Korn and he quickly acknowledged and changed it. Ok. I'll stop and I'll try to resist from written any more. Far more has been written about this than the possibly 1 character change to set this correctly. And by the way, if the current default is kept, it probably needs to be set it when "emulate sh" or "emulate bash" is in effect. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-08-05 11:19 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-07-31 2:38 Weird exit caused in a trap DEBUG which sources a file Rocky Bernstein 2008-07-31 9:01 ` Peter Stephenson 2008-07-31 10:05 ` Rocky Bernstein 2008-08-01 12:29 ` Rocky Bernstein 2008-08-01 13:37 ` Peter Stephenson 2008-08-01 15:21 ` Rocky Bernstein 2008-08-01 15:31 ` Peter Stephenson 2008-08-02 11:21 ` Rocky Bernstein 2008-08-03 10:42 ` Peter Stephenson 2008-08-03 11:28 ` Rocky Bernstein 2008-08-03 11:50 ` Peter Stephenson 2008-08-05 11:18 ` Rocky Bernstein
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).