Mac OS X terminal.app sometimes sometimes starts interpreting newlines differently! Can this be fixed?

Question

A few times now, I've had Mac OS X Terminal end up in an odd state, whereby newlines aren't interpreted as they normally are. It's as if they're doing the line feed part, but not the carriage return. For example, I might ordinarily see something like this:

% git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#

But when Terminal ends up in this odd mode, I get this instead:

% git status
# On branch master
                  # Untracked files:
                                    #   (use "git add <file>..." to include in what will be committed)
                                                                                                      #

I can create a new Terminal window to fix this, but that's a bit annoying. I'd like to keep the same window active, if possible, in case I need something in the scrollback buffer. Is there something I can do to fix things in place when it goes wrong like this?

(I don't know if it's relevant, but I normally get this when quitting emacs. Every now and again, I do something wrong, and select another command by accident instead of C-x C-c. My fingers cancel it before I've even realised what's going on, so I don't know which command it might be, but once emacs has gone, the terminal is in this funny new mode.)

Answer 1

When this issue comes up again, issue the following command in the terminal:

reset

This should reset your terminal to defaults and hopefully resolve your problem.

Answer 2

When early terminals (and printers) received an LF (ASCII 10) character they would advance the cursor (print head) to the next line without moving it horizontally. So a sequence of characters/words separated by only LFs would form what looks like a stair case. This is what you are seeing.

When a program wanted to move to the beginning of the next line, they would set CR (ASCII 13) and LF to the terminal. CR moves cursor to the beginning of the current line and LF advances to the next line.

The tty driver on Unix systems has a optional output post-processing that is usually enabled that converts an output LF to a combination of CR and LF.

The problem you are seeing is that the tty that your terminal emulator is using has had this part of the output post-processing disabled. You can reeanble output post-processing and the LF → CR LF conversion with this command:

stty opost onlcr

This type of output processing is often disabled in “full screen” terminal-based programs so that they have better control over the cursor. Thus, if such a program crashes (or is killed) in such a way that it can not restore the tty settings, then you are likely to end up in “stair step mode”. Since there are other tty settings that might be affected after such a crash, you might need something a bit more thorough to clean up the effects. You can reset the current tty’s settings to reasonable defaults with the following command:

stty sane

---

The reset command does much of what stty sane does as well as sending various reset/initalization control sequences to the terminal emulator.