After running Ruby scripts, almost 100% of the time, the bash command line will appear to be inactive, while in fact it's silently accepting my keystrokes without showing them to me.

This has happened with multiple versions of Ruby, through multiple OS updates; at the moment, I'm running v1.9.2p29 on OS X 10.9.2. reset fixes the problem; clear, et al, do not.

The "now you don't", etc., below is the output of unseen echo commands.

$ echo Now you see my typing...
Now you see my typing...

$ bundle exec jekyll build

$ This is the output of an unseen echo command

$ About to run "reset"

$ echo And we''re back.
And we're back.

stty -a output when things are working:

speed 9600 baud; 57 rows; 187 columns;
lflags: icanon isig -iexten echo echoe echok echoke -echonl echoctl
    -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff -ixany imaxbel iutf8
    -ignbrk brkint -inpck ignpar -parmrk
oflags: opost onlcr oxtabs onocr onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
    -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = <undef>; eof = ^D; eol = <undef>;
    eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
    min = 1; quit = ^\; reprint = ^R; start = ^Q; status = <undef>;
    stop = ^S; susp = ^Z; time = 0; werase = ^W;

stty -a output when things are not:

speed 9600 baud; 57 rows; 187 columns;
lflags: -icanon isig -iexten -echo echoe -echok echoke -echonl echoctl
    -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
iflags: -istrip icrnl inlcr -igncr ixon -ixoff -ixany imaxbel iutf8
    -ignbrk brkint -inpck ignpar -parmrk
oflags: opost onlcr oxtabs onocr onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
    -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = <undef>; eof = <undef>; eol = <undef>;
    eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U;
    lnext = <undef>; min = 1; quit = ^\; reprint = <undef>;
    start = ^Q; status = <undef>; stop = ^S; susp = ^Z; time = 0;
    werase = <undef>;

I notice, in particular, that in lflags, echo has become -echo.

Not sure what is causing this, or what other settings / diagnostics I should check.

  • 1
    same question on ask different: apple.stackexchange.com/q/122964/7057 – glenn jackman Mar 3 '14 at 20:15
  • True. Different audiences, but appropriate for either site, IMHO. If I get an answer in once place, I'll close the other question with a link to the solved one. I'll resist the urge to leave a "same comment on superuser..." response to your comment over there. :-) – Paul Roub Mar 3 '14 at 21:35
  • Have you tested any other terminal emulators? Is this specific to terminal.app? – terdon Mar 4 '14 at 0:12
  • 2
    PaulRoub, @glennjackman's point is valid. Cross-posting the exact same question is considered abusive behavior. We can debate the validity of this position but it is the current status quo. – terdon Mar 4 '14 at 0:14
  • @PaulRoub - The crossing of the comments is one of the main reasons why cross posting is typically not tolerated on the SE sites. Please either close this one or the other. As an answerer it's extremely annoying that I would have to "construct" the position of a Q + any A's by jumping across multiple sites. – slm Mar 4 '14 at 1:01

When you type this in your prompt:

$ And now you don't.

This is triggering a command line continuation. You apparently do not have your secondary prompt set on OSX (I'm guessing on the prompt thing) but your issue is because you're using that particular string, "$ And now you don't.`".

When you type this:

$ echo And we''re back.
And were back.

You're closing off the continuation. Try a different string to see if the same issue holds true.

NOTE: The bottom line issue is your use of '....'.

  • 1
    I didn't type "And now you don't". I typed echo And now you don''t, which was never shown onscreen. You're seeing the output of the echo command. There's no continuation. – Paul Roub Mar 4 '14 at 11:31
  • Editing the example to lessen confusion. – Paul Roub Mar 4 '14 at 11:51

The echo setting in the terminal driver settings specifies whether the terminal driver should echo back the characters you type. Applications like vi or modern shells at their prompt don't use that, nor do they use the terminal canonical mode, they do handle every key press and echo what you type by themselves by writing to the terminal device.

However, readline and any application using it, like bash or gdb also disable their echoing when they detect that the terminal echo has been disabled, other shells like zsh or tcsh don't.

Note that echo is always disabled at the bash (or any modern shell with their own line editor) shell prompt as readline does its own echoing. bash/readline saves the terminal settings before each prompt and sets it to the one it needs to implement its line editor (which includes disabling echo) and resets it to the saved value before running a command.

So the output of stty -a is that saved configuration. And bash/readline (but not other shells) disables its own echoing when echo is disabled in that saved configuration.

You can get the same behaviour as you're seeing by issuing:

stty -echo

Applications typically disable terminal echo when they issue a password prompt, or like the case of vi or bash above, to implement their own text editing (and then they don't use the terminal canonical mode), and they restore the settings upon exit.

Another difference in your case is that icanon has been disabled, which suggests we're more likely in the second case.

Your ruby script probably starts a visual application that fails to reset the terminal settings correctly. That could happen if that application is killed with a non-trapable signal like SIGKILL or if it's still running or suspended.

To restore the terminal settings, you can do a stty sane or reset. You may want to check that no process is still running and what application that script runs and why it's misbehaving.

  • 1
    stty sane, stty echo and (as noted in the question) reset do all fix the problem. I'm trying to figure out how to prevent the problem, which seems to be at least somewhat specific to my system, else I'd see bug reports about this somewhere. The ruby scripts are builders, gem updates -- nothing with a visual component. – Paul Roub Mar 5 '14 at 14:12
  • @PaulRoub, possibly something starts an editor with the output discarded. dtruss -f may be able to tell you what commands it runs, and/or what does the ioctl that disables echo (run dtruss stty -echo to get the ioctl number). – sch Mar 5 '14 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.