less viewer: Copy all the lines to clipboard - linux

There has already been a post in stackoverflow for VI editor for copying all the text into the clipboard. (Copy all the lines to clipboard) I want to do the same thing with the less viewer. I tried to search online for the process called "yank" and I did not find anything for it.
How do I copy all lines in the less editor into the clip board.
And I cannot close less and reopen it in vi. It is because of the fact that I have managed to load this file into the editor and while I have loaded it, the file has already been moved in the back end. It is a long story. The easiest solution for me now is to copy the contents of the file into memory.

less doesn't have a clipboard, but you may be able to get it to output what's stored in its buffers to a new file. This will only work if the entire contents of the file are buffered:
Type g to go to the top of the file
Type | (that's a pipe character, not an L or I) to indicate that you want to output to a pipe
Type $ to indicate that you want the output content to go to the end of the file
Type dd of=/path/to/new/file and press Enter
The dd command will take the piped data and save it to the file passed to the of= argument.

as an workaround you can set terminal's font size to 1, then select with mouse and copy (works for big , but not huge files).

If the file is not too big and if it fits in your terminal number of lines configured, then do the following:
Terminal > Edit > Clear to start
cat <file_name>
Terminal > Edit > Select all
Terminal > Edit > Copy

Related

Saving a flat-file through Vim add an invisible byte to the file that creates a new line

The title is not really specific, but I have trouble identifying the correct key words as I'm not sure what is going on here. For the same reason, it is possible that my question has a duplicate, as . If that's the case: sorry!
I have a Linux application that receive data via flat files. I don't know exactly how those files are generated, but I can read them without any problem. Those are short files, only a line each.
For test purpose, I tried to modify one of those files and reinjected it again in the application. But when I do that I can see in the log that it added a mysterious page break at the end of the message (resulting in the application not recognising the message)...
For the sake of example, let's say I receive a flat file, named original, that contains the following:
ABCDEF
I make a copy of this file and named it copy.
If I compare those two files using the "diff" command, it says they are identical (as I expect them to be)
If I open copy via Vi and then quit without changing nor saving anything and then use the "diff" command, it says they are identical (as I also expect them to be)
If I open copy via Vi and then save it without changing anything and then use the "diff" command, I have the following (I added the dot for layout purpose):
diff original copy
1c1
< ABCDEF
\ No newline at end of file
---
.> ABCDEF
And if I compare the size of my two files, I can see that original is 71 bytes when copy is 72.
It seems that the format of the file change when I save the file. I first thought of an encoding problem, so I used the ":set list" command on Vim to see the invisible characters. But for both files, I can see the following:
ABCDEF$
I have found other ways to do my test, But this problem still bugged me and I would really like to understand it. So, my two questions are:
What is happening here?
How can I modify a file like that without creating this mysterious page break?
Thank you for your help!
What happens is that Vim is set by default to assume that the files you edit end with a "newline" character. That's normal behavior in UNIX-land. But the "files" your program is reading look more like "streams" to me because they don't end with a newline character.
To ensure that those "files" are written without a newline character, set the following options before writing:
:set binary noeol
See :help 'eol'.

Continuing a macro across buffers in vim

I've got a large config file that i'm in the process of splitting out into individual ones based on section.
My workflow is like this:
Visual select the block of text in the main file (v)
Cut the text into the kill buffer (d)
Open a new buffer (:sp newfile.pp)
Paste the text (p)
Save the file with a new name and close the buffer (:wq! somefile.pp)
I tried creating a macro to do this, basically taking the steps above, but add (q a) right before cutting the text, and q again right after pasting. My macro stops as soon as the new buffer is open and won't run the paste command. I have to do this by hand.
Ideally: those steps above would complete to the point where I'd be left with the :wq! entered into the command line just waiting for me to give a filename and hit enter to close and save the buffer.
Is this possible, and how would I accomplish it without writing a script?
Edit
Found another faster way to do the same thing:
Visual select the text
Start typing a (:) command.. vim helpfully prefixes the command line to indicate an operation on your selection
:w filename.pp
Delete the block with (g v d)
Still curious why my recorded macro stops when a new buffer is created, though.
I had the same issue as you. I found out that the q after the p was not stopping the macro recording. I hope this is what you were seeing. To populate register a with content you can run (the ^# is entered by ctrl-v, ctrl-j):
let #a="d:sp! newfile.pp^#p"

How do I make commands like cat and less keep tab characters?

Is there a way to make cat, less etc. print tab characters instead of tabs being converted to spaces? I am annoyed by this when I copy code from the terminal to an editor.
I am seeing two problems here.
First, destination editor can covert TAB to number of spaces. Some
editor has default feature to convert TAB to number of spaces. If
you disable this feature TAB character you copied from terminal will
be copied as TAB(instead of space) to an editor.
Windows Notepad++ has similar feature
. If you are using vim, this page will be helpful for
vim tab and space conversion
Another, source file in your case terminal may be representing tab
as spaces, please check that first. You can use cat -t filename to
see if you have any TAB in source file or not. That command will
display TAB character as ^I.
It seems this is not possible with less (see answer to the same question on unix.stackexchange).
As a workaround, it works with cat or, for some minimal paging capabilities, with the more command.

What is a "buffer" in VIM?

When VIM refers to a file im editing as a "buffer"...what exactly does it mean? Whenever I edit the file in shell or in the application, it refers to the copy of the file as a buffer. I was curious as to what exactly this meant, but couldn't find anything on it. Any help would be appreciated.
From :help windows-intro, as linked by icktoofay in a comment:
A buffer is the in-memory text of a file ... [which is] loaded into memory for editing. The original file remains unchanged until you write the buffer to the file.
That is, a buffer represents the actual loaded/working data itself.
You can think of it as similar to the Windows clipboard. You can use it to cut, copy and paste text snippets.
But you can have multiple "buffers" open at the same time. And each buffer can have a name.
See VI Tutorial: Manipulating Text:
A named buffer is another method to move or duplicate text... first position the cursor at the material you want to copy. Next make a copy of the desired text by using the yank command. This places the copied text into a temporary buffer...

In Vim, what is the "alternate file"?

I just ran :help registers in Vim and noticed that # 'contains the name of the alternate file'.
I have seen an example for renaming files that goes like this:
" Save the current file, foo.txt, as bar.txt
:w bar.txt
" Start editing bar.txt
:e#
So apparently in that case, the file you just saved out is the "alternate file."
Can someone give me a more general definition for the "alternate file" and what else you might use it for?
The alternate file is the file that was last edited in the current window. Actually when you use some command to open a new buffer, if the buffer that was displayed had a filename associated with it, that filename is recorded as alternate file name.
See :help alternate-file.
Very useful for...
Pasting in the name of a file I've just been looking at into the current file.
You can use <C-R># for this in insert mode or "#p in normal mode.
Not that useful for...
Jumping back and forth between two files. It does the job very well, but this is just something I don't generally need to do.
Even in the example given, I'd probably use:saveas bar.txt instead.
An Example:
Say if you're doing a bit of C programming and want to call some function. You can't remember the name of the function, so you place a mark on your current location mA and jump into several different files using tags or grep to find out where the function is declared and what it's actually called.
Ah - found it. You can copy the name and return to the mark yiw'A
Uh-oh - we also need to #include the file! Easy - just use the alternate file name register to paste the file name in... Gi#include"<C-R>#"
Be pleased that you've avoided the distraction of having to go back to the function's declaration and copy out the file name via :let #"=#% or something similar.
What I'd rather do when jumping between files:
When editing two files, it's probably easier to split them, so you can keep both on screen at the same time. If I'm editing 2 files I'll usually be comparing them in some way.
Usually I'm interested in 1-3 files (any more and I get confused). I'll often jump into or directly open many other files. Marking the interesting files, or traversing the jump list is usually the way to get around in this case.
If you're editing C/C++ where you're switching between a file and it's header, use a plugin! It will be much more convenient.
I use it in the buffer context to return to the last buffer that I was editing
vim foo bar
:n
:e#
will take you back to foo in that case
I 've always interpreted the "alternate file" as being the "previous file", so it is an handy way to jump back to the buffer you were editing.

Resources