Terminal echoing permanently turned off

[mahemoff]

This happens when a byebug session is active and a Unicorn request times out. It also seems to happen when a request comes in while another request is being debugged. Seen on iTerm 2 running tmux.

To replicate:

• Create new Rails project and run the server
• bundle exec rails g resource Thing
• Add byebug to ThingController#index method
• Visit /things. Byebug will become active in the Rails server console
• Wait a minute. You'll see E, ERROR -- : worker=0 PID:7102 timeout (61s > 60s), killing
• Hit ctrl-c. Now your terminal echo is off. (Type "reset" in shell to restore it.)

[deivid-rodriguez]

Hi @mahemoff, thanks for the report. I'm gonna have a look at #63 which seems related and hopefully I'll find a fix for this one too. Cheers!

[deivid-rodriguez]

Hi @mahemoff, I can reproduce the issue following your steps but I'm not sure why it happens. Need to further study this...

[mahemoff]

Thanks for looking at it @deivid-rodriguez

[mccalluc]

FWIW, if I hit ctrl-c while byebug has stopped execution (for example, running rspec), when I get back to the terminal my input is not echoed: ie, Unicorn or Rails is not needed to reproduce this.

(reset gets things working again. Thanks!)

[deivid-rodriguez]

Thanks for that info @mccalluc !

So I can reproduce this issue using:

• rspec + pry
• rspec + byebug

But it works fine if I use

• minitest+ pry
• minitest + byebug

So maybe this is an rspec issue. @myronmarston, do you have any ideas?

[myronmarston]

@myronmarston, do you have any ideas?

No :(. RSpec doesn't do anything special with stdin/stdout or with the terminal.

[deivid-rodriguez]

Thanks @myronmarston

Maybe @banister have heard of this happening in pry before?

In any case, I'll try to have a look at this when I get time.

[x-yuri]

I was able to reduce it to:

$ ruby 1.rb

[1, 6] in 1.rb
   1: require 'byebug'
   2: trap('INT') do
   3:   exit!(1)
   4: end
   5: byebug
=> 6: puts 'test'
(byebug) $

Run, press Ctrl-C, and there you go unable to see what you input. Based on this code from rspec.

[bronson]

I'm running into this while trying to debug Rails. minitest, not rspec, but everything else sounds similar.

Would adding a reset command to byebug be an easy fix? Just some simple command to switch the echo back on.

EDIT: pry-byebug didn't help but byebug remote seems to be working.

[deivid-rodriguez]

Just tried @x-yuri's script using readline 7.0 and I can't reproduce this anymore. Can someone confirm?

[x-yuri]

I can't reproduce it even with rspec (if I do it right):

Gemfile:

source 'https://rubygems.org'
gem 'rspec', '3.5.0'
gem 'byebug', '9.0.6'

$ bundle

spec/1_spec.rb:

require 'rubygems'
require 'bundler/setup'
require 'byebug'

RSpec.describe :terminal do
  it 'stops echoing symbols' do
    byebug
  end
end

$  rspec
Return value is: nil

[1, 9] in /home/yuri/_/2/spec/1_spec.rb
   1: require 'rubygems'
   2: require 'bundler/setup'
   3: require 'byebug'
   4:
   5: RSpec.describe :terminal do
   6:   it 'stops echoing symbols' do
   7:     byebug
=> 8:   end
   9: end
(byebug) ^C
(byebug) I can see what I type

P.S. readline-6.3.008

[evolve2k]

I'm running Rails 4.2.7.1 and byebug 9.0.6 and using iTerm2 as my terminal.
I came here because I'm having this exact problem with what I type not showing in terminal after byebug kicks in.

So I'm here to confirm that as of 9.0.6 this is still an issue.

[glennpratt]

iTerm2 3.0.15

Caused occasionally with binding.pry (though I can't say how exactly).

[leanand]

I tried debugging this issue. I could find that problem lies with Readline.readline method.
My assumption is that when a child process invokes the Readline method and it is waiting for the input, It changes the terminal settings. When that process is killed using SIGKILL signal, the changes done by readline is not reverted back.

Here is a sample code I tried reproducing,

require "readline"

pid = Process.fork do
  puts "Try killing this process #{Process.pid}"
  Readline.readline("byebug>")
end

Process.wait

I hope this is helpful.

[sirupsen]

A faster work-around is using stty sane.

[radixhound]

For future searchers, a clarification to what @sirupsen means:

When we get into that situation, we can send stty sane to the shell from the byebug session (using backticks) and get the cursor back.

`stty sane`

Here's a demo:

Just to add to that, I just created an iTerm shortcut that I can use to reset it with one press of command+option+2 (Mac):

[qortex]

Does this mean it is inevitable and cannot be fixed upstream?

stty sane works for me on Fedora 31.

Edit: I now see this PR. Any chance to get it merged?

[jpwhitaker]

stty sane is not working for me on osx catalina / iterm

[deivid-rodriguez]

Edit: I now see this PR. Any chance to get it merged?

I missed this edit sorry, I never got it to work properly, that's why it never got merged.

[evolve2k]

This bug in byebug literally is a major blocking bug that renders the tool unusable.

We’d all love to see it fixed 🙏

[x-yuri]

@evolve2k Can you describe how to reproduce it? Last time I tried, I couldn't.