67

From time to time I have to run a command-line tool (a Python script) whose output seems to break my terminal. After the execution is finished, the typing feedback is gone (I can't see what I'm typing), and also line breaks are not displayed. This happens if the terminal is started remotely via Putty, and also locally when using gnome-terminal.

For example, after the problem happens, if I type ENTER pwd ENTER, I would expect to see:

[userA@host006 ~]$
[userA@host006 ~]$ pwd
/home/userA
[userA@host006 ~]$

But actually the output is:

[userA@host006 ~]$ [userA@host006 ~]$ /home/userA
                                                             [userA@host006 ~]$

The only way to fix it is to close that terminal and start a new one.

Maybe be related: the script output contains some terminal-based formatting (e.g. invert foreground/background to highlight some status messages). If I dump this output to a file I can see things like [07mSome Message Here[0m.

Any ideas what I could do to prevent this?

E.Z.
  • 5,663
  • 7
  • 38
  • 60
  • You seem to be in a subshell that you need to exit from to get back to your original terminal. Just try exit;pwd –  Jul 16 '13 at 17:17
  • 3
    This is off-topic for SO; belongs on [unix.se] or [su]. That said, you can usually fix a broken terminal session by blind typing `stty sane`, which restores your terminal to 'sane' settings. – Jim Garrison Jul 16 '13 at 17:20
  • 1
    Also, when you have terminal problems, you can try fixing them using `reset` or `stty sane`. – cabad Jul 16 '13 at 17:20
  • related http://askubuntu.com/questions/171449/shell-does-not-show-typed-in-commands-reset-works-but-what-happened – Ciro Santilli新疆棉花TRUMP BAN BAD Feb 12 '17 at 15:14

2 Answers2

153

Execute the command reset and your terminal should be restored (reference).

This issue happens generally when dumping binary data to the terminal STDOUT which when the escape codes received are processed can do anything from change the color of the text, disable echo, even change character set.

The easy way to avoid this is to ensure you do not dump unknown binary data to the terminal, and if you must then convert it to hexadecimal to ensure it doesn't change the terminal settings.

Bas Peeters
  • 3,085
  • 4
  • 30
  • 47
Joshua Briefman
  • 3,356
  • 2
  • 18
  • 33
  • Thanks a lot! In my case running ipython inside a Kubernetes container didn't show the typed input, executing `reset` fixed it. – dusan Feb 20 '17 at 14:02
  • 1
    I have the same issue when I execute `bash x.sh` inside a ssh shell. `reset` does help but if I execute the .sh file again, the issue reappears. Do you have any idea? (the .sh file basically just execute `sbt package` to build my scala project) – Minh Thai Aug 23 '17 at 11:02
13

To elaborate on Joshua Briefman's answer, executing reset -c will only reset the control characters responsible for your problem:

tset, reset - terminal initialization

Usage: tset [options] [terminal]

Options:
  -c          set control characters
  -e ch       erase character
  -I          no initialization strings
  -i ch       interrupt character
  -k ch       kill character
  -m mapping  map identifier to type
  -Q          do not output control key settings
  -r          display term on stderr
  -s          output TERM set command
  -V          print curses-version
  -w          set window-size

Also note the following form the command's manual:

Note, you may have to type

<LF>reset<LF>

(the line-feed character is normally control-J) to get the terminal to work, as carriage-return may no longer work in the abnormal state. Also, the terminal will often not echo the command.

HoldOffHunger
  • 10,963
  • 6
  • 53
  • 100
Bas Peeters
  • 3,085
  • 4
  • 30
  • 47