Ruby: run irb from trap context?












2















The following example is given in the book Programming Ruby 1.9 & 2.0:



require 'irb'

trap "INT" do
IRB.start
end

count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
end


Unfortunately, if I run this code with my Ruby 2.5.1 setup I get the following ThreadError (run_irb.rb is the name of the file with the code above):



    24: from run_irb.rb:8:in `<main>'
23: from run_irb.rb:8:in `loop'
22: from run_irb.rb:12:in `block in <main>'
21: from run_irb.rb:12:in `sleep'
20: from run_irb.rb:4:in `block in <main>'
19: from /usr/lib/ruby/2.5.0/irb.rb:376:in `start'
18: from /usr/lib/ruby/2.5.0/irb/init.rb:17:in `setup'
17: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `init_config'
16: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `new'
15: from /usr/lib/ruby/2.5.0/irb/locale.rb:32:in `initialize'
14: from /usr/lib/ruby/2.5.0/irb/locale.rb:108:in `load'
13: from /usr/lib/ruby/2.5.0/irb/locale.rb:124:in `find'
12: from /usr/lib/ruby/2.5.0/irb/locale.rb:145:in `search_file'
11: from /usr/lib/ruby/2.5.0/irb/locale.rb:157:in `each_localized_path'
10: from /usr/lib/ruby/2.5.0/irb/locale.rb:167:in `each_sublocale'
9: from /usr/lib/ruby/2.5.0/irb/locale.rb:158:in `block in each_localized_path'
8: from /usr/lib/ruby/2.5.0/irb/locale.rb:150:in `block in search_file'
7: from /usr/lib/ruby/2.5.0/rubygems.rb:213:in `try_activate'
6: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find_by_path'
5: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find'
4: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `each'
3: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1064:in `block in find_by_path'
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:40:in `require'
1: from /usr/lib/ruby/2.5.0/monitor.rb:185:in `mon_enter'
/usr/lib/ruby/2.5.0/monitor.rb:185:in `lock': can't be called from trap context (ThreadError)


Is there a way to get the irb run from the trap context with Ruby 2.5.1?










share|improve this question























  • I can understand why there is an error for this. What is the use-case?

    – Max
    Nov 20 '18 at 19:38
















2















The following example is given in the book Programming Ruby 1.9 & 2.0:



require 'irb'

trap "INT" do
IRB.start
end

count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
end


Unfortunately, if I run this code with my Ruby 2.5.1 setup I get the following ThreadError (run_irb.rb is the name of the file with the code above):



    24: from run_irb.rb:8:in `<main>'
23: from run_irb.rb:8:in `loop'
22: from run_irb.rb:12:in `block in <main>'
21: from run_irb.rb:12:in `sleep'
20: from run_irb.rb:4:in `block in <main>'
19: from /usr/lib/ruby/2.5.0/irb.rb:376:in `start'
18: from /usr/lib/ruby/2.5.0/irb/init.rb:17:in `setup'
17: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `init_config'
16: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `new'
15: from /usr/lib/ruby/2.5.0/irb/locale.rb:32:in `initialize'
14: from /usr/lib/ruby/2.5.0/irb/locale.rb:108:in `load'
13: from /usr/lib/ruby/2.5.0/irb/locale.rb:124:in `find'
12: from /usr/lib/ruby/2.5.0/irb/locale.rb:145:in `search_file'
11: from /usr/lib/ruby/2.5.0/irb/locale.rb:157:in `each_localized_path'
10: from /usr/lib/ruby/2.5.0/irb/locale.rb:167:in `each_sublocale'
9: from /usr/lib/ruby/2.5.0/irb/locale.rb:158:in `block in each_localized_path'
8: from /usr/lib/ruby/2.5.0/irb/locale.rb:150:in `block in search_file'
7: from /usr/lib/ruby/2.5.0/rubygems.rb:213:in `try_activate'
6: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find_by_path'
5: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find'
4: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `each'
3: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1064:in `block in find_by_path'
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:40:in `require'
1: from /usr/lib/ruby/2.5.0/monitor.rb:185:in `mon_enter'
/usr/lib/ruby/2.5.0/monitor.rb:185:in `lock': can't be called from trap context (ThreadError)


Is there a way to get the irb run from the trap context with Ruby 2.5.1?










share|improve this question























  • I can understand why there is an error for this. What is the use-case?

    – Max
    Nov 20 '18 at 19:38














2












2








2








The following example is given in the book Programming Ruby 1.9 & 2.0:



require 'irb'

trap "INT" do
IRB.start
end

count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
end


Unfortunately, if I run this code with my Ruby 2.5.1 setup I get the following ThreadError (run_irb.rb is the name of the file with the code above):



    24: from run_irb.rb:8:in `<main>'
23: from run_irb.rb:8:in `loop'
22: from run_irb.rb:12:in `block in <main>'
21: from run_irb.rb:12:in `sleep'
20: from run_irb.rb:4:in `block in <main>'
19: from /usr/lib/ruby/2.5.0/irb.rb:376:in `start'
18: from /usr/lib/ruby/2.5.0/irb/init.rb:17:in `setup'
17: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `init_config'
16: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `new'
15: from /usr/lib/ruby/2.5.0/irb/locale.rb:32:in `initialize'
14: from /usr/lib/ruby/2.5.0/irb/locale.rb:108:in `load'
13: from /usr/lib/ruby/2.5.0/irb/locale.rb:124:in `find'
12: from /usr/lib/ruby/2.5.0/irb/locale.rb:145:in `search_file'
11: from /usr/lib/ruby/2.5.0/irb/locale.rb:157:in `each_localized_path'
10: from /usr/lib/ruby/2.5.0/irb/locale.rb:167:in `each_sublocale'
9: from /usr/lib/ruby/2.5.0/irb/locale.rb:158:in `block in each_localized_path'
8: from /usr/lib/ruby/2.5.0/irb/locale.rb:150:in `block in search_file'
7: from /usr/lib/ruby/2.5.0/rubygems.rb:213:in `try_activate'
6: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find_by_path'
5: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find'
4: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `each'
3: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1064:in `block in find_by_path'
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:40:in `require'
1: from /usr/lib/ruby/2.5.0/monitor.rb:185:in `mon_enter'
/usr/lib/ruby/2.5.0/monitor.rb:185:in `lock': can't be called from trap context (ThreadError)


Is there a way to get the irb run from the trap context with Ruby 2.5.1?










share|improve this question














The following example is given in the book Programming Ruby 1.9 & 2.0:



require 'irb'

trap "INT" do
IRB.start
end

count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
end


Unfortunately, if I run this code with my Ruby 2.5.1 setup I get the following ThreadError (run_irb.rb is the name of the file with the code above):



    24: from run_irb.rb:8:in `<main>'
23: from run_irb.rb:8:in `loop'
22: from run_irb.rb:12:in `block in <main>'
21: from run_irb.rb:12:in `sleep'
20: from run_irb.rb:4:in `block in <main>'
19: from /usr/lib/ruby/2.5.0/irb.rb:376:in `start'
18: from /usr/lib/ruby/2.5.0/irb/init.rb:17:in `setup'
17: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `init_config'
16: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `new'
15: from /usr/lib/ruby/2.5.0/irb/locale.rb:32:in `initialize'
14: from /usr/lib/ruby/2.5.0/irb/locale.rb:108:in `load'
13: from /usr/lib/ruby/2.5.0/irb/locale.rb:124:in `find'
12: from /usr/lib/ruby/2.5.0/irb/locale.rb:145:in `search_file'
11: from /usr/lib/ruby/2.5.0/irb/locale.rb:157:in `each_localized_path'
10: from /usr/lib/ruby/2.5.0/irb/locale.rb:167:in `each_sublocale'
9: from /usr/lib/ruby/2.5.0/irb/locale.rb:158:in `block in each_localized_path'
8: from /usr/lib/ruby/2.5.0/irb/locale.rb:150:in `block in search_file'
7: from /usr/lib/ruby/2.5.0/rubygems.rb:213:in `try_activate'
6: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find_by_path'
5: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find'
4: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `each'
3: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1064:in `block in find_by_path'
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:40:in `require'
1: from /usr/lib/ruby/2.5.0/monitor.rb:185:in `mon_enter'
/usr/lib/ruby/2.5.0/monitor.rb:185:in `lock': can't be called from trap context (ThreadError)


Is there a way to get the irb run from the trap context with Ruby 2.5.1?







ruby irb






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 20 '18 at 19:14









Min-Soo PipefeetMin-Soo Pipefeet

20211




20211













  • I can understand why there is an error for this. What is the use-case?

    – Max
    Nov 20 '18 at 19:38



















  • I can understand why there is an error for this. What is the use-case?

    – Max
    Nov 20 '18 at 19:38

















I can understand why there is an error for this. What is the use-case?

– Max
Nov 20 '18 at 19:38





I can understand why there is an error for this. What is the use-case?

– Max
Nov 20 '18 at 19:38












1 Answer
1






active

oldest

votes


















2















Ruby 2.0 does not allow Mutex#lock within a signal handler




According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)



An alternative method is to use an exception/rescue and execute an IRB session from an interrupt like this:



require 'irb'

count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end


The above will correctly trap an interrupt and allow an IRB session to start. I did notice that IRB.start won't give you a local execution context, so you may want to look at binding.irb that let's you start a more useful debugging session like this:



$ ruby thread-test.rb
1
2
^C
[1] irb(main)>

From: /work/_scratch/thread-test/thread-test.rb @ line 11 :

6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end

[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2


I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.






share|improve this answer





















  • 2





    Since Ruby 2.4 there's binding.irb to get the local context. You don't need pry.

    – Max
    Nov 20 '18 at 19:35











  • @Max no way!?!? TIL!

    – Gavin Miller
    Nov 20 '18 at 19:36











  • Thx. Works great. But if I change break to retry or next I can only once Ctrl-C to irb, the following Ctrl-Cs are ignored. Any idea why?

    – Min-Soo Pipefeet
    Nov 21 '18 at 6:18













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53399991%2fruby-run-irb-from-trap-context%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2















Ruby 2.0 does not allow Mutex#lock within a signal handler




According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)



An alternative method is to use an exception/rescue and execute an IRB session from an interrupt like this:



require 'irb'

count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end


The above will correctly trap an interrupt and allow an IRB session to start. I did notice that IRB.start won't give you a local execution context, so you may want to look at binding.irb that let's you start a more useful debugging session like this:



$ ruby thread-test.rb
1
2
^C
[1] irb(main)>

From: /work/_scratch/thread-test/thread-test.rb @ line 11 :

6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end

[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2


I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.






share|improve this answer





















  • 2





    Since Ruby 2.4 there's binding.irb to get the local context. You don't need pry.

    – Max
    Nov 20 '18 at 19:35











  • @Max no way!?!? TIL!

    – Gavin Miller
    Nov 20 '18 at 19:36











  • Thx. Works great. But if I change break to retry or next I can only once Ctrl-C to irb, the following Ctrl-Cs are ignored. Any idea why?

    – Min-Soo Pipefeet
    Nov 21 '18 at 6:18


















2















Ruby 2.0 does not allow Mutex#lock within a signal handler




According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)



An alternative method is to use an exception/rescue and execute an IRB session from an interrupt like this:



require 'irb'

count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end


The above will correctly trap an interrupt and allow an IRB session to start. I did notice that IRB.start won't give you a local execution context, so you may want to look at binding.irb that let's you start a more useful debugging session like this:



$ ruby thread-test.rb
1
2
^C
[1] irb(main)>

From: /work/_scratch/thread-test/thread-test.rb @ line 11 :

6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end

[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2


I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.






share|improve this answer





















  • 2





    Since Ruby 2.4 there's binding.irb to get the local context. You don't need pry.

    – Max
    Nov 20 '18 at 19:35











  • @Max no way!?!? TIL!

    – Gavin Miller
    Nov 20 '18 at 19:36











  • Thx. Works great. But if I change break to retry or next I can only once Ctrl-C to irb, the following Ctrl-Cs are ignored. Any idea why?

    – Min-Soo Pipefeet
    Nov 21 '18 at 6:18
















2












2








2








Ruby 2.0 does not allow Mutex#lock within a signal handler




According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)



An alternative method is to use an exception/rescue and execute an IRB session from an interrupt like this:



require 'irb'

count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end


The above will correctly trap an interrupt and allow an IRB session to start. I did notice that IRB.start won't give you a local execution context, so you may want to look at binding.irb that let's you start a more useful debugging session like this:



$ ruby thread-test.rb
1
2
^C
[1] irb(main)>

From: /work/_scratch/thread-test/thread-test.rb @ line 11 :

6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end

[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2


I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.






share|improve this answer
















Ruby 2.0 does not allow Mutex#lock within a signal handler




According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)



An alternative method is to use an exception/rescue and execute an IRB session from an interrupt like this:



require 'irb'

count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end


The above will correctly trap an interrupt and allow an IRB session to start. I did notice that IRB.start won't give you a local execution context, so you may want to look at binding.irb that let's you start a more useful debugging session like this:



$ ruby thread-test.rb
1
2
^C
[1] irb(main)>

From: /work/_scratch/thread-test/thread-test.rb @ line 11 :

6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end

[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2


I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 20 '18 at 19:41

























answered Nov 20 '18 at 19:33









Gavin MillerGavin Miller

33.8k18106169




33.8k18106169








  • 2





    Since Ruby 2.4 there's binding.irb to get the local context. You don't need pry.

    – Max
    Nov 20 '18 at 19:35











  • @Max no way!?!? TIL!

    – Gavin Miller
    Nov 20 '18 at 19:36











  • Thx. Works great. But if I change break to retry or next I can only once Ctrl-C to irb, the following Ctrl-Cs are ignored. Any idea why?

    – Min-Soo Pipefeet
    Nov 21 '18 at 6:18
















  • 2





    Since Ruby 2.4 there's binding.irb to get the local context. You don't need pry.

    – Max
    Nov 20 '18 at 19:35











  • @Max no way!?!? TIL!

    – Gavin Miller
    Nov 20 '18 at 19:36











  • Thx. Works great. But if I change break to retry or next I can only once Ctrl-C to irb, the following Ctrl-Cs are ignored. Any idea why?

    – Min-Soo Pipefeet
    Nov 21 '18 at 6:18










2




2





Since Ruby 2.4 there's binding.irb to get the local context. You don't need pry.

– Max
Nov 20 '18 at 19:35





Since Ruby 2.4 there's binding.irb to get the local context. You don't need pry.

– Max
Nov 20 '18 at 19:35













@Max no way!?!? TIL!

– Gavin Miller
Nov 20 '18 at 19:36





@Max no way!?!? TIL!

– Gavin Miller
Nov 20 '18 at 19:36













Thx. Works great. But if I change break to retry or next I can only once Ctrl-C to irb, the following Ctrl-Cs are ignored. Any idea why?

– Min-Soo Pipefeet
Nov 21 '18 at 6:18







Thx. Works great. But if I change break to retry or next I can only once Ctrl-C to irb, the following Ctrl-Cs are ignored. Any idea why?

– Min-Soo Pipefeet
Nov 21 '18 at 6:18






















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53399991%2fruby-run-irb-from-trap-context%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







這個網誌中的熱門文章

Xamarin.form Move up view when keyboard appear

Post-Redirect-Get with Spring WebFlux and Thymeleaf

Anylogic : not able to use stopDelay()