13

locate ... | less outputs a long path, which is shown as several lines in the terminal, although it is actually a single line.

I copy the path from the terminal by selecting the text with mouse and hitting Ctrl+Shift+C. When I paste it into a text file, I get unwanted change-line in the text, exactly in the same way that it is shown in the terminal.

But I remember sometimes I can copy a long path output by locate ... | less, without introducing unwanted line-change, and sometimes I can't. I don't realize if I do something differently.

So I wonder how to make sure the problem will not happen? Thanks!

My OS: Ubuntu 12.04.

My terminal: Gnome Terminal 3.4.1.1

  • But Ctrl+Shift+C can sometime copy a long line without copying change-line. Still different problems, I think. – Tim Apr 26 '14 at 0:06
  • So your Q is more about why or how to control this behavior? – slm Apr 26 '14 at 0:12
  • Yes. I copy text out of the terminal using the shortcut key (which I guess is the quickest way), not by directing the output to a file – Tim Apr 26 '14 at 0:13
  • Is there anything more about when the behavior is one way vs. the other? – slm Apr 26 '14 at 0:14
3

Instead of copying what is displayed on the terminal (only what fits on the screen, with), copy the actual text. Use one of the external utilities xsel or xclip (they have mostly the same features, I'll use xsel in this answer) to copy data from or to the X clipboard. To copy to the clipboard, pass the desired content on standard input. When pasting from the clipboard, the content is written to standard output.

In less, use the | command to pipe a bunch of lines through a command. Scroll to the first line you want to act on, type mm to set a mark, scroll to the last line, and type |mxsel -b and press Enter. Two marks are predefined: ^ for the beginning of the file, $ for the end of the file. Thus, to copy the whole file, use <|$xsel -b. To copy a single line, use mm|mxsel -b and Enter.

Remove the -b option to copy to the primary selection instead of the clipboard.

3

The real behavior of this is the following:

if you are in less and you have a file with a very long line, then if you scroll over the long line down and scroll back up, you have multiple lines, when copying the whole text. After that, when you scroll the splitted lines down over the bottom of the terminal and scroll the lines up again, the line breaks will be removed again.

For visualization:

enter image description here

2

In less, if you select wrapped multiple lines of text and then copy it, it'll come down as one line.

If you press PgUp then copy the same text, it'll come down as multiple lines.

PgDn is fine, arrows are fine. But PgUp causes the text to be split up.

1

You can copy the lines of output without extra newlines (line breaks) if the text was output directly to the terminal.
The terminal can keep track of where the real line ends are.

But if the lines were output by less or a similar pager program, the terminal does not know where the newlines are. The pager uses the terminal as a full screen of characters, and tells the terminal "put these characters there" and operations like scrolling. But, for the terminal, there's no way to see where newlines are intended.

  • 2
    I found that sometimes I copy the line breaks and sometimes I don't. It is inconsistent across time. Today both happened when I Ctrl-shift-c from locate <something> | less in two different cases. – Tim Sep 28 '14 at 21:37
  • Less draws its screen itself, normally, so that the terminal does not see where lines end. But less can be configured do actually do nothing for short files fitting the screen heigt. So it's possible that the difference between the cases was that less was in a different mode. (take a look at echo $LESS, maybe there are interesting options for less.) – Volker Siegel Oct 2 '14 at 11:21
  • @Tim this has been bugging me for years too. Maybe @niknah's answer suggests the cause? I often switch between -S mode so maybe that makes it worse too. – Dan Gravell Sep 8 '16 at 8:22
  • 1
    @Tim: I discovered something that might or might not be true on your OS & less version: the behavior of copy varies depending on how I've arrived at the target line in less. If I'm searching forwards then the copy doesn't include the wrapping newlines (i.e., it copies the original long line content). However, if I've searched backwards through the file to get to the target line, then the copy includes the newlines and splits the long line into multiple separate lines. Seems consistent across Mac and Linux for me. – erik.weathers Mar 14 '18 at 3:16
0

If the goal is to copy & paste, I use cat instead of less or more and then the terminal captures it as it actually is rather than as it is being displayed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.