When I run the following command in Terminal.app:

echo -e "a\tb\tc\td\te\tf\tg\tyo"

I should get the following output (using a 40-column window so that lines don't wrap here, and replacing tabs with spaces so that the correct amount of space is shown here):

a       b       c       d       e       
f       g       yo

But instead, I get this output:

a       b       c       d       e       y

As you can see, the f and g are missing.

After trying various strings, I think the problem is that a tab at the end of a line does not advance the output to the next line, but instead leaves the output cursor one character before the line end. For example (still assuming a 40-column terminal), 4 tabs puts the cursor at position 32 of line 1. Another tab should put the cursor at position 0 of line 2, but instead the cursor is at position 39 of line 1, leaving room for one more character to be printed—and even at that point, the cursor is not advanced to the next line, so another tab will put us back to position 39. Hence, an unlimited number of (single-character + tab) strings will be silently ignored.

I've experimented with a variety of:

  • shells (including bash, sh, and csh)
  • terminal widths (including 40 columns, 80, and many others)
  • terminal types (including vt100 and xterm-color)
  • terminal character encodings (including UTF-8 and ascii)
  • terminal settings (including Escape non-ASCII input)

Also, a friend ran similar commands on a Linux system with a different terminal, and did not encounter the same bug.

Anybody know how to fix this? I'd be much obliged, as this bug is making it might tricky to debug some home-made shell scripts running on tab-separated files.

  • 1
    For reference I see the same behaviour as you in OS X's built-in Terminal.app, but iTerm2 seems to soft-wrap the tabs onto a new line as you would expect.
    – maniacyak
    Nov 29 '12 at 1:18
  • 2
    You may want to submit a bug report to Apple. I am able to replicate this issue, and it is definitely not supposed to happen...
    – daviewales
    Dec 3 '12 at 13:51
  • 2
    It’s a question of interpretation of the terminal specification(s). Terminal interprets a particular clause to mean that the cursor should not advance to the next line when tabs are written at the end of a line, but that surprises some people and should perhaps be treated as a bug and adjusted to interpret the rules differently.
    – Chris Page
    Dec 5 '12 at 18:15
  • 1
    @daviewales I filed a bug report a couple of hours ago. I don't think I can share the link here, but I'll keep this thread apprised of any results. Dec 5 '12 at 19:43
  • 2
    Well, there may be two separate issues involved. What I was referring to is that the VT100 User Guide vt100.net/docs/vt100-ug/table3-10.html says of tab “Move the cursor to the next tab stop, or to the right margin if no further tab stops are present on the line”. As far as I am aware, the VT100 does not line-wrap tabs. The issue with a character at the last tab stop not advancing to the next line may be a bug no matter how you interpret the VT100 docs, but it may also be viewed as a valid outcome of the fact that the cursor doesn’t advance to the next line when the character is output.
    – Chris Page
    Dec 7 '12 at 6:28

This has to do with line breaks. Terminal is looking for either a space, or a continuos string of characters to make a line break. In this case the first opportunity it sees to break the line is between the y and the o. The "y" is shown because the last character in an extended line is shown in the last place to hint the user that something is happening there.


You could try:

echo -e "a \tb \tc \td \te \tf \tg \tyo"

and everything will appear as you'd expect it.

also something like

echo -e "ab\tcd\tef\tgh\tij\tkl\tmn\tyo"

should break between the "k" and "l"

Still this is odd behavior and defiantly worth a bug/radar report


You must log in to answer this question.

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