* zsh exits after delete-char-or-list and two ^Cs @ 2004-08-25 17:04 Danek Duvall 2004-08-27 0:22 ` Bart Schaefer 2004-09-01 17:36 ` Peter Stephenson 0 siblings, 2 replies; 11+ messages in thread From: Danek Duvall @ 2004-08-25 17:04 UTC (permalink / raw) To: zsh-workers This happens with 4.0.6, 4.2.0 and 4.2.1, the first two on Linux, the latter on Solaris. If I use delete-char-or-list, then hit control-C twice, the first time cancels the command-line where I hit ^D, and the second one exits the shell. This happens both with my normal config and running zsh -f. With the latter I can get the shell to exit (after using delete-char-or-list) by hitting control-A a few times, then diddling around with the cursor keys and typing a bit (though I can't find a consisten way of reproducing this). Note that the shell simply exits, it doesn't crash. Has this been brought up before? Thanks, Danek ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-08-25 17:04 zsh exits after delete-char-or-list and two ^Cs Danek Duvall @ 2004-08-27 0:22 ` Bart Schaefer 2004-09-01 18:10 ` Peter Stephenson 2004-09-01 17:36 ` Peter Stephenson 1 sibling, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2004-08-27 0:22 UTC (permalink / raw) To: zsh-workers On Wed, 25 Aug 2004, Danek Duvall wrote: > This happens with 4.0.6, 4.2.0 and 4.2.1, the first two on Linux, the > latter on Solaris. If I use delete-char-or-list, then hit control-C > twice, the first time cancels the command-line where I hit ^D, and the > second one exits the shell. Looks like the interrupt handler isn't getting reset after the first ctrl-C. I don't yet know why not, but this means that the default SIGINT handler is called on the second ^C, which of course ends the process. There also appears to be a bug in 4.2.x with "zle -I" and "zle -R". This should work: TRAPINT() { zle -I && zle send-break } because "zle -I" is supposed to return zero only when zle is active. However, I get: TRAPINT:zle: widgets can only be called when ZLE is active In any case there are numerous workarounds involving trapping ^C or using "stty" to disable interrupt ... but they all have drawbacks. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-08-27 0:22 ` Bart Schaefer @ 2004-09-01 18:10 ` Peter Stephenson 2004-09-01 19:44 ` Bart Schaefer 0 siblings, 1 reply; 11+ messages in thread From: Peter Stephenson @ 2004-09-01 18:10 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote: > There also appears to be a bug in 4.2.x with "zle -I" and "zle -R". This > should work: > > TRAPINT() { zle -I && zle send-break } > > because "zle -I" is supposed to return zero only when zle is active. > However, I get: > > TRAPINT:zle: widgets can only be called when ZLE is active The first problem is that zle -I doesn't have the same test as zle <widget>. It's reasonable that it should. The second problem is that the test currently includes the function context. In this case, we've been called from a trap. I'm not convinced this test is necessary; I think it should work as long as zleactive is set, so that we are in a nested context. So I've removed that test. If there are cases where this is problematic, they should be fixed up separately. Actually, the context could be SFC_COMPLETE or SFC_CWIDGET for old- and new-style completion functions, in which case we don't want to allow normal zle widgets. However, I think in this case the existing tests for incompctlfunc and incompfunc are good enough. A simple test seems to indicate they are. It still doesn't work as you expect, since you get the normal effect of ^C as well as the effect of the send-break. I'm not convinced that's a bug, yet. Index: Doc/Zsh/zle.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v retrieving revision 1.39 diff -u -r1.39 zle.yo --- Doc/Zsh/zle.yo 29 Jul 2004 14:22:21 -0000 1.39 +++ Doc/Zsh/zle.yo 1 Sep 2004 18:02:00 -0000 @@ -507,7 +507,8 @@ The status is zero if zle is active and the current zle display has been invalidated (even if this was by a previous call to `tt(zle -I)'), -else one. +else one. More precisely, the status is zero if zle is currently in a +usable state, i.e. a zle widget can be called immediately. ) item(var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)( Invoke the specified widget. This can only be done when ZLE is Index: Src/Zle/zle_thingy.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_thingy.c,v retrieving revision 1.13 diff -u -r1.13 zle_thingy.c --- Src/Zle/zle_thingy.c 2 Jun 2004 22:15:02 -0000 1.13 +++ Src/Zle/zle_thingy.c 1 Sep 2004 18:02:02 -0000 @@ -619,6 +619,23 @@ /**/ static int +zle_usable() +{ + return zleactive && !incompctlfunc && !incompfunc +#if 0 + /* + * PWS experiment: commenting this out allows zle widgets + * in signals, hooks etc. I'm not sure if this has a down side; + * it ought to be that zleactive is good enough to test whether + * widgets are callable. + */ + && sfcontext == SFC_WIDGET +#endif + ; +} + +/**/ +static int bin_zle_call(char *name, char **args, UNUSED(Options ops), UNUSED(char func)) { Thingy t; @@ -629,10 +646,9 @@ if (!wname) { if (saveflag) zmod = modsave; - return (!zleactive || incompctlfunc || incompfunc || - sfcontext != SFC_WIDGET); + return !zle_usable(); } - if(!zleactive || incompctlfunc || incompfunc || sfcontext != SFC_WIDGET) { + if(!zle_usable()) { zwarnnam(name, "widgets can only be called when ZLE is active", NULL, 0); return 1; @@ -685,7 +701,7 @@ static int bin_zle_invalidate(UNUSED(char *name), UNUSED(char **args), UNUSED(Options ops), UNUSED(char func)) { - if (zleactive) { + if (zle_usable()) { if (!trashedzle) trashzle(); return 0; -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-09-01 18:10 ` Peter Stephenson @ 2004-09-01 19:44 ` Bart Schaefer 2004-09-02 9:19 ` Peter Stephenson 0 siblings, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2004-09-01 19:44 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers On Wed, 1 Sep 2004, Peter Stephenson wrote: > bin_zle_invalidate(UNUSED(char *name), UNUSED(char **args), UNUSED(Options ops), UNUSED(char func)) > { > + if (zle_usable()) { > if (!trashedzle) > trashzle(); > return 0; The effect of this is going to be that "zle -I" has no effect when called from completion widgets, where previously it could. Is that really the intent? I'd think you wanted something more like: if (zleactive) { if (!trashedzle) trashzle(); return zle_usable()? 0 : 1; } (Though perhaps not precisely that either.) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-09-01 19:44 ` Bart Schaefer @ 2004-09-02 9:19 ` Peter Stephenson 2004-09-02 15:15 ` Bart Schaefer 0 siblings, 1 reply; 11+ messages in thread From: Peter Stephenson @ 2004-09-02 9:19 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote: > The effect of this is going to be that "zle -I" has no effect when called > from completion widgets, where previously it could. Is that really the > intent? > > I'd think you wanted something more like: > > if (zleactive) { > if (!trashedzle) > trashzle(); > return zle_usable()? 0 : 1; > } > > (Though perhaps not precisely that either.) Well, that would do, if suitably documented. It looks like it would be more sensible to have the test for whether a zle widget is callable separate from the return status for zle -I. However, it's a bit late now. Index: Doc/Zsh/zle.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v retrieving revision 1.39 diff -u -r1.39 zle.yo --- Doc/Zsh/zle.yo 29 Jul 2004 14:22:21 -0000 1.39 +++ Doc/Zsh/zle.yo 2 Sep 2004 09:15:35 -0000 @@ -505,9 +505,12 @@ Note that there are normally better ways of manipulating the display from within zle widgets; see, for example, `tt(zle -R)' above. -The status is zero if zle is active and the current zle display has -been invalidated (even if this was by a previous call to `tt(zle -I)'), -else one. +The returned status is zero if a zle widget can be called immediately. +Note this is independent of whether the display has been invalidated. +For example, if a completion widget is active a zle widget cannot be used +and the status is one even if the display was invalidated; on the other +hand, the status may be zero if the display was invalidated by a previous +call to `tt(zle -I)'. ) item(var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)( Invoke the specified widget. This can only be done when ZLE is Index: Src/Zle/zle_thingy.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_thingy.c,v retrieving revision 1.13 diff -u -r1.13 zle_thingy.c --- Src/Zle/zle_thingy.c 2 Jun 2004 22:15:02 -0000 1.13 +++ Src/Zle/zle_thingy.c 2 Sep 2004 09:15:36 -0000 @@ -619,6 +619,23 @@ /**/ static int +zle_usable() +{ + return zleactive && !incompctlfunc && !incompfunc +#if 0 + /* + * PWS experiment: commenting this out allows zle widgets + * in signals, hooks etc. I'm not sure if this has a down side; + * it ought to be that zleactive is good enough to test whether + * widgets are callable. + */ + && sfcontext == SFC_WIDGET +#endif + ; +} + +/**/ +static int bin_zle_call(char *name, char **args, UNUSED(Options ops), UNUSED(char func)) { Thingy t; @@ -629,10 +646,9 @@ if (!wname) { if (saveflag) zmod = modsave; - return (!zleactive || incompctlfunc || incompfunc || - sfcontext != SFC_WIDGET); + return !zle_usable(); } - if(!zleactive || incompctlfunc || incompfunc || sfcontext != SFC_WIDGET) { + if(!zle_usable()) { zwarnnam(name, "widgets can only be called when ZLE is active", NULL, 0); return 1; @@ -685,10 +701,15 @@ static int bin_zle_invalidate(UNUSED(char *name), UNUSED(char **args), UNUSED(Options ops), UNUSED(char func)) { + /* + * Trash zle if trashable, but only indicate that zle is usable + * if it's possible to call a zle widget next. This is not + * true if a completion widget is active. + */ if (zleactive) { if (!trashedzle) trashzle(); - return 0; + return !zle_usable(); } else return 1; } -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-09-02 9:19 ` Peter Stephenson @ 2004-09-02 15:15 ` Bart Schaefer 2004-09-03 9:37 ` Peter Stephenson 0 siblings, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2004-09-02 15:15 UTC (permalink / raw) To: zsh-workers On Thu, 2 Sep 2004, Peter Stephenson wrote: > It looks like it would be more sensible to have the test for whether a > zle widget is callable separate from the return status for zle -I. What about zle -R ? I think (but haven't applied it yet) that with this patch we have zle && echo "widgets callable" # I'm least certain of this zle -I && echo "Display invalidated and widgets callable" zle -R && echo "Display refreshed and zle active" Is that right? This covers all bases, assuming it's harmless to call zle -R even when you don't really care whether the display is refreshed. Unless one might need to know that the display has been invalidated even when widgets are not callable? I'm having a hard time coming up with that. > However, it's a bit late now. Well, no, not really -- if in fact "zle" with no arguments does correctly mean "widgets callable", then "zle -I" could continue as "zle active". Perhaps this was all a documentation problem to begin with. Sorry to nit-pick, but: > Index: Doc/Zsh/zle.yo > =================================================================== > +The returned status is zero if a zle widget can be called immediately. > +Note this is independent of whether the display has been invalidated. > +For example, if a completion widget is active a zle widget cannot be used > +and the status is one even if the display was invalidated; on the other > +hand, the status may be zero if the display was invalidated by a previous > +call to `tt(zle -I)'. Isn't it more accurate to say "the status may be nonzero even if the display was invalidated by a previous call"? With the rest of the patch as it stands, the status is never zero when completion widgets are active, even when the display was previously invalidated -- but the above seems to imply that the status might be zero in that event. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-09-02 15:15 ` Bart Schaefer @ 2004-09-03 9:37 ` Peter Stephenson 2004-09-03 18:59 ` Bart Schaefer 0 siblings, 1 reply; 11+ messages in thread From: Peter Stephenson @ 2004-09-03 9:37 UTC (permalink / raw) To: zsh-workers (Oliver says the In-reply-to and References format should work better like this. Tell me if it doesn't.) Bart Schaefer wrote: > On Thu, 2 Sep 2004, Peter Stephenson wrote: > > > It looks like it would be more sensible to have the test for whether a > > zle widget is callable separate from the return status for zle -I. > > What about zle -R ? > > I think (but haven't applied it yet) that with this patch we have > > zle && echo "widgets callable" # I'm least certain of this > zle -I && echo "Display invalidated and widgets callable" > zle -R && echo "Display refreshed and zle active" > > Is that right? Yes, noting that testing for `display invalidated' and `display refreshed' doesn't form part of the return status (I think that's what you mean but it's not clear from the output). > This covers all bases, assuming it's harmless to call zle -R even when you > don't really care whether the display is refreshed. Unless one might need > to know that the display has been invalidated even when widgets are not > callable? I'm having a hard time coming up with that. I agree, it's just a question of how much of a stickler you are for having the return status reflecting `command did what I expected' rather than `command did something and tested for something else'. Unless someone is using ERR_RETURN inside widgets (yuk!) I don't suppose this is a problem. > Sorry to nit-pick, but: > > > Index: Doc/Zsh/zle.yo > > =================================================================== > > +The returned status is zero if a zle widget can be called immediately. > > +Note this is independent of whether the display has been invalidated. > > +For example, if a completion widget is active a zle widget cannot be used > > +and the status is one even if the display was invalidated; on the other > > +hand, the status may be zero if the display was invalidated by a previous > > +call to `tt(zle -I)'. > > Isn't it more accurate to say "the status may be nonzero even if the > display was invalidated by a previous call"? With the rest of the patch > as it stands, the status is never zero when completion widgets are active, > even when the display was previously invalidated -- but the above seems to > imply that the status might be zero in that event. Ah, I think I see: you're reading the two cases around the semicolon in conjunction, while I meant them to be independent. However, your emendation doesn't get across quite the point I wanted, which is "if you call zle -I and it returns zero, it may be that the display was invalidated by a previous call rather than the current one". Maybe reversing the sense of the second case is better. You might well say "who cares", but I want to emphasis calling zle -I multiple times has no bad effect. Maybe the English for that is "calling zle -I multiple times has no bad effects". -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-09-03 9:37 ` Peter Stephenson @ 2004-09-03 18:59 ` Bart Schaefer 2004-09-07 14:08 ` Peter Stephenson 2004-09-08 14:23 ` Peter Stephenson 0 siblings, 2 replies; 11+ messages in thread From: Bart Schaefer @ 2004-09-03 18:59 UTC (permalink / raw) To: zsh-workers On Fri, 3 Sep 2004, Peter Stephenson wrote: > (Oliver says the In-reply-to and References format should work better > like this. Tell me if it doesn't.) (Looks fine. What are you using as a mail reader?) > Bart Schaefer wrote: > > zle && echo "widgets callable" # I'm least certain of this > > zle -I && echo "Display invalidated and widgets callable" > > zle -R && echo "Display refreshed and zle active" > > > > Is that right? > > Yes, noting that testing for `display invalidated' and `display > refreshed' doesn't form part of the return status (I think that's what > you mean but it's not clear from the output). Hmm. OK, that's not so good, because it breaks "zle -I || ..." in the case where you want to know whether the display was NOT invalidated. (Maybe there's never a reason to care about that, but ...) > I agree, it's just a question of how much of a stickler you are for > having the return status reflecting `command did what I expected' rather > than `command did something and tested for something else'. I'm quite willing to have "zle -I" go back to testing for "invalidating the display was a sensible thing to attempt" provided that "zle" (no args) tests for "widgets callable", and that all of this is documented more clearly. > I want to emphasis calling zle -I multiple times has no bad effect. > Maybe the English for that is "calling zle -I multiple times has no bad > effects". Yeah. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-09-03 18:59 ` Bart Schaefer @ 2004-09-07 14:08 ` Peter Stephenson 2004-09-08 14:23 ` Peter Stephenson 1 sibling, 0 replies; 11+ messages in thread From: Peter Stephenson @ 2004-09-07 14:08 UTC (permalink / raw) To: zsh-workers > On Fri, 3 Sep 2004, Peter Stephenson wrote: > > Bart Schaefer wrote: > > > zle && echo "widgets callable" # I'm least certain of this > > > zle -I && echo "Display invalidated and widgets callable" > > > zle -R && echo "Display refreshed and zle active" > > > > > > Is that right? > > > > Yes, noting that testing for `display invalidated' and `display > > refreshed' doesn't form part of the return status (I think that's what > > you mean but it's not clear from the output). > > Hmm. OK, that's not so good, because it breaks "zle -I || ..." in the > case where you want to know whether the display was NOT invalidated. > (Maybe there's never a reason to care about that, but ...) I don't think there is, in fact, but for the sake of logic it's probably worth changing. I've looked at the pattern of usage of zle -I in the various functions I've got and I never test the return value at all: either zle wasn't active, or it's been invalidated, and either are good enough for me. (I do, however, test [[ -o zle ]] beforehand to avoid having to load it if it wasn't in use.) It would require putting the test back to testing for zleactive. That means your original example wouldn't work, but as you say that's really a problem with the documentation for when I feel fit enough to look at the zle documentation again. The display is refreshed if and only if zle is active on zle -R, so that doesn't need changing. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-09-03 18:59 ` Bart Schaefer 2004-09-07 14:08 ` Peter Stephenson @ 2004-09-08 14:23 ` Peter Stephenson 1 sibling, 0 replies; 11+ messages in thread From: Peter Stephenson @ 2004-09-08 14:23 UTC (permalink / raw) To: zsh-workers This rearranges the status. Most of this is just clarification. I move documentation for calling zle on its own to the top, since it was a bit buried. Index: Doc/Zsh/zle.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v retrieving revision 1.40 diff -u -r1.40 zle.yo --- Doc/Zsh/zle.yo 2 Sep 2004 14:34:39 -0000 1.40 +++ Doc/Zsh/zle.yo 8 Sep 2004 14:20:18 -0000 @@ -312,6 +312,7 @@ cindex(calling widgets) cindex(widgets, defining) cindex(defining widgets) +xitem(tt(zle)) xitem(tt(zle) tt(-l) [ tt(-L) | tt(-a) ] [ var(string) ... ]) xitem(tt(zle) tt(-D) var(widget) ...) xitem(tt(zle) tt(-A) var(old-widget) var(new-widget)) @@ -323,10 +324,18 @@ xitem(tt(zle) tt(-K) var(keymap)) xitem(tt(zle) tt(-F) [ tt(-L) ] [ var(fd) [ var(handler) ] ]) xitem(tt(zle) tt(-I)) -xitem(tt(zle) var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...) -item(tt(zle))( +item(tt(zle) var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)( The tt(zle) builtin performs a number of different actions concerning -ZLE. Which operation it performs depends on its options: +ZLE. + +With no options and no arguments, only the return status will be +set. It is zero if ZLE is currently active and widgets could be +invoked using this builtin command and non-zero otherwise. +Note that even if non-zero status is returned, zle may still be active as +part of the completion system; this does not allow direct calls to ZLE +widgets. + +Otherwise, which operation it performs depends on its options: startitem() item(tt(-l) [ tt(-L) | tt(-a) ])( @@ -392,7 +401,9 @@ This command can safely be called outside user defined widgets; if zle is active, the display will be refreshed, while if zle is not active, the command has no effect. In this case there will usually be no other -arguments. The status is zero if zle was active, else one. +arguments. + +The status is zero if zle was active, else one. ) item(tt(-M) var(string))( As with the tt(-R) option, the var(string) will be displayed below the @@ -505,12 +516,10 @@ Note that there are normally better ways of manipulating the display from within zle widgets; see, for example, `tt(zle -R)' above. -The returned status is zero if a zle widget can be called immediately. -Note this is independent of whether the display has been invalidated. -For example, if a completion widget is active a zle widget cannot be used -and the status is one even if the display was invalidated; on the other -hand, the status may be zero if the display was invalidated by a previous -call to `tt(zle -I)'. +The returned status is zero if zle was invalidated, even though +this may have been by a previous call to `tt(zle -I)' or by a system +notification. To test if a zle widget may be called at this point, execute +tt(zle) with no arguments and examine the return status. ) item(var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)( Invoke the specified widget. This can only be done when ZLE is @@ -540,10 +549,6 @@ it should call the tt(beep) widget directly. ) enditem() - -With no options and no arguments, only the return status will be -set. It is zero if ZLE is currently active and widgets could be -invoked using this builtin command and non-zero if ZLE is not active. ) enditem() Index: Src/Zle/zle_thingy.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_thingy.c,v retrieving revision 1.14 diff -u -r1.14 zle_thingy.c --- Src/Zle/zle_thingy.c 2 Sep 2004 14:34:39 -0000 1.14 +++ Src/Zle/zle_thingy.c 8 Sep 2004 14:20:21 -0000 @@ -709,7 +709,7 @@ if (zleactive) { if (!trashedzle) trashzle(); - return !zle_usable(); + return 0; } else return 1; } -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: zsh exits after delete-char-or-list and two ^Cs 2004-08-25 17:04 zsh exits after delete-char-or-list and two ^Cs Danek Duvall 2004-08-27 0:22 ` Bart Schaefer @ 2004-09-01 17:36 ` Peter Stephenson 1 sibling, 0 replies; 11+ messages in thread From: Peter Stephenson @ 2004-09-01 17:36 UTC (permalink / raw) To: zsh-workers Danek Duvall wrote: > This happens with 4.0.6, 4.2.0 and 4.2.1, the first two on Linux, the > latter on Solaris. If I use delete-char-or-list, then hit control-C twice, > the first time cancels the command-line where I hit ^D, and the second one > exits the shell. Obviously if I tried to look at this today after my holiday it would just get me all frustrated. So that would be a bad idea. Here's a patch. The problem is that there's a special test to see if there was an EOF character (which must be ^D for the bug to turn up in this particular form) at the start of the line. This test was erroneously triggered on the second ^C as the input character hadn't changed from the ^D used to list completion. The first ^C didn't trigger it because the line hadn't yet been emptied. The functions don't pass back the state properly, so it's difficult to check what actually happened (i.e. EOF or interrupt); maybe it can be done better than this. Note that errflag isn't set at the point of the patch if there was a ^C. This seems to be deliberate; see the handling of EINTR in getkey(). I think it's also to do with the lack of distinction between an interruption and an EOF---in loop(), we exit the command loop, and hence the shell, if we get an end-of-input token and errflag is *not* set. I thought about resetting lastchar at the start of each line. However, I think there are cases where that doesn't work. Index: Src/Zle/zle_main.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_main.c,v retrieving revision 1.49 diff -u -r1.49 zle_main.c --- Src/Zle/zle_main.c 13 Jul 2004 09:41:37 -0000 1.49 +++ Src/Zle/zle_main.c 1 Sep 2004 17:15:15 -0000 @@ -687,12 +687,19 @@ reselectkeymap(); selectlocalmap(NULL); bindk = getkeycmd(); - if (!ll && isfirstln && !(zlereadflags & ZLRF_IGNOREEOF) && - lastchar == eofchar) { - eofsent = 1; - break; - } if (bindk) { + if (!ll && isfirstln && !(zlereadflags & ZLRF_IGNOREEOF) && + lastchar == eofchar) { + /* + * Slight hack: this relies on getkeycmd returning + * a value for the EOF character. However, + * undefined-key is fine. That's necessary because + * otherwise we can't distinguish this case from + * a ^C. + */ + eofsent = 1; + break; + } if (execzlefunc(bindk, zlenoargs)) handlefeep(zlenoargs); handleprefixes(); -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-09-08 14:23 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-08-25 17:04 zsh exits after delete-char-or-list and two ^Cs Danek Duvall 2004-08-27 0:22 ` Bart Schaefer 2004-09-01 18:10 ` Peter Stephenson 2004-09-01 19:44 ` Bart Schaefer 2004-09-02 9:19 ` Peter Stephenson 2004-09-02 15:15 ` Bart Schaefer 2004-09-03 9:37 ` Peter Stephenson 2004-09-03 18:59 ` Bart Schaefer 2004-09-07 14:08 ` Peter Stephenson 2004-09-08 14:23 ` Peter Stephenson 2004-09-01 17:36 ` 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).