Skip Menu |
Report information
Id: 128900
Status: open
Priority: 0/
Queue: perl6

Owner: lizmat <bitcard [at] liz.nl>
Requestors: cpan [at] zoffix.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [LHF] Make ^C in REPL abort the current line, if one is running
Download (untitled) / with headers
text/plain 663b
If you start the REPL and then run: sleep 50000 Or any other long running command, it'll "hang" for a long time. If you attempt to press Control+C to abort that line, you end up exiting REPL. When ^C is pressed while a line in REPL is running, it should abort that line, instead of exiting. And the current behaviour is to be maintained in that pressing ^C when nothing is running exitings the REPL. Relevant IRC conversation: http://irclog.perlgeek.de/perl6/2016-08-11#i_13007834 Specifically: [lizmat]: fwiw, I think it should be pretty trivial to catch SIGINT in a signal handler, then die("SIGINTED") in there, and then let the CATCH handler cleanup
To: "Zoffix Znet (via RT)" <perl6-bugs-followup [...] perl.org>
Subject: Re: [perl #128900] [LHF] Make ^C in REPL abort the current line, if one is running
Date: Fri, 12 Aug 2016 16:09:32 +0200
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
CC: bugs-bitbucket [...] rt.perl.org
Working on this now Show quoted text
> On 11 Aug 2016, at 20:35, Zoffix Znet (via RT) <perl6-bugs-followup@perl.org> wrote: > > # New Ticket Created by Zoffix Znet > # Please include the string: [perl #128900] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=128900 > > > > If you start the REPL and then run: > > sleep 50000 > > Or any other long running command, it'll "hang" for a long time. If you attempt to press Control+C to abort that line, you end up exiting REPL. > > When ^C is pressed while a line in REPL is running, it should abort that line, instead of exiting. And the current behaviour is to be maintained in that pressing ^C when nothing is running exitings the REPL. > > Relevant IRC conversation: http://irclog.perlgeek.de/perl6/2016-08-11#i_13007834 > > Specifically: > [lizmat]: fwiw, I think it should be pretty trivial to catch SIGINT in a signal handler, then die("SIGINTED") in there, and then let the CATCH handler cleanup
Date: Fri, 12 Aug 2016 22:35:09 +0200
CC: bugs-bitbucket [...] rt.perl.org
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Re: [perl #128900] [LHF] Make ^C in REPL abort the current line, if one is running
To: "Zoffix Znet (via RT)" <perl6-bugs-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.3k
Fixed with be7ce04 , tests needed Turns out this was slightly more involved than just setting up a CATCH block, as the CATCH block will only be seen either in the executing thread, or in the .tap block of the signal handler. So in the end, I decided to always start the code in a separate thread with “start”, and let another Promise be reset by ^C, and then wait for either promise to be kept. Show quoted text
> On 11 Aug 2016, at 20:35, Zoffix Znet (via RT) <perl6-bugs-followup@perl.org> wrote: > > # New Ticket Created by Zoffix Znet > # Please include the string: [perl #128900] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=128900 > > > > If you start the REPL and then run: > > sleep 50000 > > Or any other long running command, it'll "hang" for a long time. If you attempt to press Control+C to abort that line, you end up exiting REPL. > > When ^C is pressed while a line in REPL is running, it should abort that line, instead of exiting. And the current behaviour is to be maintained in that pressing ^C when nothing is running exitings the REPL. > > Relevant IRC conversation: http://irclog.perlgeek.de/perl6/2016-08-11#i_13007834 > > Specifically: > [lizmat]: fwiw, I think it should be pretty trivial to catch SIGINT in a signal handler, then die("SIGINTED") in there, and then let the CATCH handler cleanup
This was reverted as it caused accidental breakage of variable declarations (RT#128973)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org