6

In some terminal sessions, a space is inserted where long lines wrap. When copying multiple lines with a mouse, the inserted trailing space on each line is included. When pasted, one must manually delete these extra spaces.

Is there some terminal setting that can prevent the insertion of these extra spaces for long, wrapping lines of text?

If it matters, I'm currently using iTerm on Mac OS X, but the problem happens depending on what machine I ssh into.

4
  • I've edited the question. It's currently always iTerm on Mac OS X. (However, it's happened using other terminal programs over the years. I'm just finally getting around to trying to get a solution for the problem.) The extra spacing happens some of the time based on what machine (and, presumably, what OS it's running). Jul 10, 2015 at 22:35
  • A space is inserted - do you mean a blank line? It could be the terminal state does not agree w/ the kernel's reported rows/cols count - do stty -a and compare it to your actual device. This is especially likely ina layered terminal setup - such as many ssh sessions.
    – mikeserv
    Jul 11, 2015 at 1:14
  • No I mean a space. If the terminal window is 80 columns wide and the line of text being printed is longer than that, what happens is that the text gets printed up to and including column 79. In column 80 a space is printed. Then the text continues on the next line. If you, using your mouse, then select the two lines, copy them, then paste them, that extraneous space is included that you then have to go back and delete after pasting. Jul 11, 2015 at 5:38
  • It's not a space. It's a terminal glitch - many terminals have it. It usually has to do with autowrap. The escape sequence printf \\33\[7l might free you of it, but then your shell and all of the applications you run will need to where to wrap.
    – mikeserv
    Jul 11, 2015 at 5:49

1 Answer 1

0

It sounds like a bug in iTerm2's workaround for vim's workaround for VT100 line-wrapping.

That may sound roundabout, but here is an explanation:

  • terminal emulators store the text that you select as rows, and for practical purposes do not wrap those rows.
  • most terminal emulators make special provision to allow you to select text that wraps around the right margin as if it is one long string. They do this by detecting a sequence of printing characters written (and wrapping) around the margin.
  • VT100 line-wrapping presents a special problem because the terminal ignores (nonprinting) control characters (such as carriage return) when the cursor is on the right margin. Think of it as a way to suppress an unnecessary blank line.
  • programs which use cursor-addressing (such as text editors) do not necessarily write text which you see as wrapped in a manner that makes the terminal see it as wrapped. There can be a gap.
  • vim is an exception here, using a special case to fill in that gap by writing a dummy character which makes the wrapping happen, followed by cursor addressing to the next line — and overwriting the dummy character.

The terminal emulator has to keep track of this hint and build up a long wrapped line. There was a bug report for iTerm2 which may be related (and was closed a couple of months before this question):

You must log in to answer this question.

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