5

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
...
done.

$ 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
    -extproc
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
    -extproc
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.

Paul Roub
  • 277

2 Answers2

0

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 '....'.

slm
  • 10,859
0

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.

sch
  • 367