6

The only two applications I've been able to reproduce the issue with are tail and cat. If I tail -f log/development.log or any file for that matter, and press CTRL-C to quit, when I type additional commands there is no keyboard echo to the screen. If I hit enter, the commands are run and they generate output, but still keyboard echo is broken.

An interesting tidbit is that I have been able to restore keyboard echo a few different ways:

1) stty echo

2) irb

running either of those commands will restore keyboard echo until one of the offending commands is exited with CTRL-C again.

I have tried setting my terminal emulation to rxvt and xterm-color, changing this does not seem to make a difference.

Improve this question
4
  • 1
    What version of Mac OS X? Have you customized any settings in Terminal? I'm running 10.6.4 with a stock Terminal config and this doesn't happen for me. Any chance the files that you're tailing/cat'ing have control characters in them? Are you using the stock tail/cat, or did you build your own from source, or with a tool like MacPorts/Fink/Homebrew?
    – Spiff
    Sep 16, 2010 at 4:25
  • 10.6.4 and I wiped my Terminal preferences to defaults and the issue still occurs. If I tail an empty file it does not happen, but if it has 1 newline it will happen. Using stock tail/cat from Mac OS.
    – Michael Guterl
    Sep 16, 2010 at 12:27
  • I went digging through my .profile removing random bits of things and discovered it is MacPorts bash-completion that is causing the issue. I'll investigate further...
    – Michael Guterl
    Sep 16, 2010 at 12:51
  • 1
    In the event anyone else comes across this, there is an official bug report here: trac.macports.org/ticket/25968
    – Michael Guterl
    Sep 16, 2010 at 12:56

4 Answers 4

Reset to default
4

To reset your terminal use the reset command.

I don't understand why tail and cat are causing this problem since they shouldn't be doing anything to affect the terminal's line settings. Are you using Terminal.app or another terminal? Are you using Bash or another shell? Are you running screen? Do you have anything else that may be using curses or doing some other screen manipulation? Do you have a trap set for Ctrl-C?

Improve this answer
2
  • I'm using Terminal.app, bash, not running screen, I don't think I have any other curses libraries interfering and I don't have a trap set for Ctrl-C that I'm aware of.
    – Michael Guterl
    Sep 16, 2010 at 12:25
  • Tailing/catting binary files can often cause this as they could contain any number of unintentional escape codes.
    – chillitom
    May 27, 2014 at 18:21
2

This is a bug with MacPorts bash completion. The bug report is here.

I fixed it by changing my shell to /opt/local/bin/bash provided by macports, using this.

Improve this answer
1

To summarize what Michael found: the stock MacOS Bash, v3.2.48(1)-release, plus bash_completion as supplied by MacPorts causes some commands (tail(1), cat(1), etc.) to disable TTY echo in the shell after they are terminated, as described in this bug. The fix is to use the MacPorts version of Bash, as describe here.

For what it's worth, I found the same bug when using bash-completion supplied by Homebrew with the stock version of Bash.

Improve this answer
1
  • I added the second link to Michael's answer. If you feel this made your post redundant, you can consider deleting it.
    – Daniel Beck ♦
    Jan 24, 2011 at 19:34
0

I have this problem within byobu (running screen, I believe) within an ssh session to a linux box. If I pipe, say, an rsync command requiring a password to less, less can get a bit confused. Ctrl-C gets me out of it, but keyboard echo is sometimes not working afterwards.

@Michael Guterl's solution fixes the problem:

stty echo

ps: I'm running the built-in bash from apple: 4.2.45(2)-release (i386-apple-darwin12.3.0)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .