Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ^C in REPL abort the current line, if one is running #5558

Open
p6rt opened this issue Aug 11, 2016 · 5 comments
Open

Make ^C in REPL abort the current line, if one is running #5558

p6rt opened this issue Aug 11, 2016 · 5 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented Aug 11, 2016

Migrated from rt.perl.org#128900 (status was 'open')

Searchable as RT128900$

@p6rt
Copy link
Author

p6rt commented Aug 11, 2016

From @zoffixznet

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

@p6rt
Copy link
Author

p6rt commented Aug 12, 2016

From @lizmat

Working on this now

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-archive.perl.org/perl6/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

@p6rt
Copy link
Author

p6rt commented Aug 12, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Aug 12, 2016

From @lizmat

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.

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-archive.perl.org/perl6/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

@p6rt
Copy link
Author

p6rt commented Aug 18, 2016

From @zoffixznet

This was reverted as it caused accidental breakage of variable declarations (RT#​128973)

@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

1 participant