In bash, I can type Ctrl+u it "cuts" text behind my cursor.
Then when I press Ctrl+y it pastes the text back.
Is there a file where the cut text is stored?
The "clipboard" -- actually called the kill ring -- is implemented by the readline library. It is not persistent, so it is not saved in a file.
There are lots of keystroke commands for "kill"ing and "yank"ing text, which are described in the bash manual:
Killing text means to delete the text from the line, but to save it away for later use, usually by yanking (re-inserting) it back into the line. (‘Cut’ and ‘paste’ are more recent jargon for ‘kill’ and ‘yank’.)
More complete documentation is in this section of the manual.
xsel can copy and paste to three different "clipboards". By default, it uses the X Window System primary selection, which is basically whatever is currently in selection. The X Window System also has a secondary selection (which isn't used much), and a clipboard selection. You're probably looking for the clipboard selection, since that's what the desktop environment (e.g. Gnome, KDE, XFCE) uses for its clipboard. To use that with xsel:
xsel --clipboard < new-clipboard-contents.txt
xsel --clipboard > current-clipboard-contents.txt
or use this link
Related
I'm using gedit. I have multiple tabs open, some are simply text that I have copied from other tabs, and haven't been saved to any file.
Is there a way to compare text that is selected in one tab to text selected in another tab? I know that I can use meld, diffuse, diff, etc., but those (afaik) require the selections to be saved to files first.
I remember using an editor (maybe emacs?) many years ago that could do something similar. But now I almost exclusively use gedit for text file editing.
Any ideas anyone?
TIA
ken
Okay, got a pointer from google:
In gedit, I created a new external tool that will run diff with the clipboard contents against the currently selected text.
Here's the bash code for the tool:
#!/bin/bash
SEL=$(cat)
diff -B <(echo -en "$SEL") <(xclip -selection c -o)
Note that this requires xclip, which is in most linux's repos. Sorry, don't know about Windoze.
I encountered a problem with my terminal where when I paste text, it is prefixed by 00~ and suffixed with 01~.
For example, I will highlight text and push Command-C. I then push Command-V into the terminal and I see those weird characters pop up at the beginning and end of the text.
For example, I can highlight text and paste it into the terminal. I then see 00~text01~.
The text can be from anywhere, even from the Terminal itself. I do not have any copy/paste plugins installed, this is just the normal Copy/Paste. I am using the default Mac Terminal without any modifications.
I did some searching online, apparently the Paste wraps the text in special characters so that certain applications will see that this is pasted text and will handle it properly. However, the terminal is not handling this correctly, and is therefore not removing the weird characters. Apparently this paste mode is called the "Bracketed Paste Mode" http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode
I found another question that gave a solution on how to solve this issue on a linux machine, but after trying that solution I still have that same problem.
Can someone tell me how I can disable bracketed paste mode for the terminal? Or tell me the right way to get rid of these annoying characters?
What happens when text is pasted
Text has made it into the "system" (e.g. X, MacOS/Aqua) copy buffer from somewhere, maybe from the same terminal. The text is not altered here.
The text is pasted into the terminal; that is, "system" sees to that the terminal (e.g. xterm) receives the unaltered character sequence from the copy buffer. The terminal is aware that this is a paste, not keyboard input.
The terminal sends the char sequence in the buffer to the program running in the foreground (a shell, an editor, whatever). To the program the received data is indistinguishable from user input through the keyboard.
Discussion
This transparency (or opaqueness? whatever) is often a good thing much like the Unix paradigm of transparent pipe plumbing in general. But sometimes programs could deal with the data better if they knew it is pasted. For example an editor like vim could switch off auto indent — after all, the code is likely indented already!
Bracketed paste
Enter bracketed paste. For principal reasons the paradigm of transparent data piping cannot be altered; but the data can be decorated with sequences which would ordinarily not appear in terminal input to mark its start and end. If the terminal is so configured — for the xterm the configuration would be to send ESC [ ? 2 0 0 4 h — the pasted data is bracketed with escape sequences: ESC [ 2 0 0 ~ <buffer contents> ESC [ 2 0 1 ~.
The foreground program receives this "decorated" data, and it's up to to the program to handle it. A naive program treats all of it as user input, which is what you see.
A good discussion of bracketed paste can be found in this article.
Remedies
There are two issues in your case: The terminal ends up unexpectedly in bracketed paste mode; and the receiving program — presumably the shell — does not handle it.
One solution is user83536's: Identify the program which leaves the terminal in that state and call it through a wrapper which simply switches bracketed paste mode off again after the program has ended.
The program probably tried to switch bracketed paste mode off but failed. One reason can be that it sends the wrong escape sequence. Try setting the TERMINAL environment variable to the value best describing your terminal.
Try to switch off bracketed paste in the offending application. In vim one would say set t_BE=. That prevents vim from putting the terminal in bracketed paste mode and when it is set in a session, sends the "end bracketed paste mode" to the terminal.
Embrace bracketed paste. It seems to be a good idea. For the bash and other programs using readline one would put set enable-bracketed-paste on. For vim one could follow the suggestions here.
This may not apply directly to your problem, but I found this symptom to probably, in my case, be caused by my editor-of-choice 'mcedit' (Midnight Commander)
To alleviate the bug problem, I added the following function to my .bashrc file:
### vvv 'function mcedit' is a fix-up for the ~0/~1 paste problem
function mcedit() { command mcedit $# ; printf '\e[?2004l' ; }
Then 'source .bashrc'
Now every time I execute 'mcedit', it automatically adds the 'printf "\e[?2004l"' when I close out to reset the "Bracketed Paste Mode"
Works for me, YMMV.
To disable bracketed paste mode in your terminal, run the following command:
printf '\e[?2004l'
To disable bracketed paste globally, on Linux, add this line to ~/.inputrc :
set enable-bracketed-paste 0
To disable only in the current running Xterm (v 372) (running bash shell version 5.1.16 (probably earlier too, but I don't know)):
% bind 'set enable-bracketed-paste 0'
With either of the above two methods, you can re-enable bracketed paste (in the current Xterm) in the obvious way, namely:
% bind 'set enable-bracketed-paste 1'
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
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
When using GNU Screen we can work with scrollback buffer also known as "copy mode" using the Ctrl+a+[ command.
In there we can copy text to the copy buffer by pressing space selecting the text and pressing space again.
Is there some way to copy this text from screen copy buffer to the X clipboard?
In my case I'm using Ubuntu 12.04 with gnome and Xorg.
You can use a CLI clipboard tool like xsel or pbpaste and the cat utility to grab contents from STDIN. The steps on Linux with xsel are as follows:
Copy text from your screen session into GNU screen's copy buffer.
Run this command within screen: cat | xsel -b
If xsel didn't report any error, now dump screen's copy buffer to STDIN: Ctrl+a+]
Send an EOF to cat to terminate it: Ctrl+d
At this point, the contents of the screen copy buffer should be in your clipboard.
EDIT: As with all X programs, xsel needs to know how to contact your X server in order to access the clipboard. You should have your DISPLAY environment variable set appropriately.
This answer works for only a scenario where your end target is to paste the copied buffer contents immediately.
The simplest way to do this is by splitting your screen into two regions. You can do this by hitting CTRL+a then |'This is not an i. It is the PIPE sign on your keyboard'
Hit CTRL+a then TAB to switch to the second region, CTRL+a then c to create a new session in the second region.
If you want to copy from nano and paste in terminal, open up the file in nano on the left region, hit CTRL+a then ESC, scroll to the start point of your copy location and hit SPACE, select the text by scrolling to the end point and hit SPACE again to mark copy.
Now, all you have to do is hit CTRL+a then TAB to switch to the region on your right and hit CTRL+a then ].
Your text will be written out to the command line. Note that you can also check for hardcopy option if you want to write directly to file.
There is a simpler and less manual way to do this. In your screen .rc file, add the following line:
bindkey -m ' ' eval 'stuff \040' 'writebuf' 'exec sh -c "/usr/bin/pbcopy < /tmp/screen-exchange"'
How to use the copy functionality:
screen -c path/to/screen/config.rc
Hit Ctrl+A then Esc to enter copy mode.
Scroll up the text buffer and find the spot you want to leave your start marker for copying, then hit space.
Scroll down and select the text you wish to copy. When you are done, hit space again.
The text will now be in your clipboard.
EDIT:
On Linux with no pbcopy but with clipit, you can use as below:
bindkey -m ' ' eval 'stuff \040' 'writebuf' 'exec sh -c "/bin/cat /tmp/screen-exchange | /bin/clipit"'
This answer applies to OS X.
After copying the desired text into the GNU Screen paste buffer using copy mode, do the following:
In any of your screen windows, type pbcopy <enter>.
Then paste your text into the terminal using the GNU Screen paste command (Ctrl-a ] unless you've changed your escape key).
If the text does not end in a newline, press <enter> to insert one.
Finally, press Ctrl-d to cause pbcopy to push the text to the system clipboard.
Then you can paste the text elsewhere in OS X as usual using Command-v or an equivalent menu option.
Since nobody seems to have directly answered the question:
Once you have copied the output you want into your buffer you need to
Open a text editor with a new file i.e. vim somefile.txt
Go into edit mode i.e. i in vim
Press Ctrl + a then ] which will dump the contents of the buffer you just filled into the text editor
ta-da!
Exit your ssh terminal session, if you are currently connected to a server.
If you are using XQuartz on Mac OS and xsel on the server. You should update the XQuartz pasteboard settings by selecting Preferences in the xQuartz application menu.
XQuartz settings:
ssh into the remote machine and try run:
xsel -p <<<"THIS IS A TEST".
Press cmd + v and "THIS IS A TEST" should be output.
I wanted a way to do this programmatically similarly to #kungfuspider and tweaked their solution to work for Ubuntu WSL running on Windows.
Setup:
Download win32yank executable and place win32yank.exe somewhere useful (I created a symbolic link to it in /usr/bin with ln -s <path to exe> /usr/bin/win32yank)
Place the following into ~/.screenrc (from #kungfuspider). You might need to modify the command to point to the correct cat and win32yank locations.
bindkey -m ' ' eval 'stuff \040' 'writebuf' 'exec sh -c "cat /tmp/screen-exchange | win32yank -i --crlf"'
Reload ~/.screenrc without killing your session by executing CTRL+a : source ~/.screenrc
How To Use:
Enter copy mode with CTRL+a [
Move around with vim style key movement or arrow keys
Start selecting text by hitting space
Highlight desired text and finish copy by hitting space again, text should now be in your Windows clipboard and can be pasted back to Ubuntu with a right-click.
Note: It is very important to finish copy with a space because that's what the bindkey command is using to map win32yank
If it's just a little bit of info that you want to copy just highlight it with your mouse and then paste it where you want.
If you're trying to get a lot of info the screen session can be logged to a file and then you can copy from the file or clean it up a bit and use it for instructions on doing things
Finally today I found a solution with mouse:
Hold down Ctrl and right click with mouse.
Copy/paste context menu shows up.
Some screens at https://michalzuber.wordpress.com/2015/01/28/gnu-screen-copy-paste-with-mouse/
I started to use macvim not only for code, but also for editing a wiki and academic writing in LaTeX. After several honeymoon moments ;-) and first customization efforts, I found a problem I can't solve:
How do I paste content from the system clipboard within a line, no matter where this content is copied from? (I use LaunchBar’s multi clipboard feature quite excessively and store mostly > 20 strings from different applications I will paste sooner or later. It works well with macvim, but not when it comes to "linewise" content.) p or P create newlines, cmd-v as well.
I neither want to add strings between tags, nor focus on other specialised settings.
I don't know how Launchbar works in this regard but all the clipboard managers I've used send a Cmd-v when you hit Enter.
MacVim, being very well integrated in the system, supports many default Mac OS X shortcuts like Cmd-o, Cmd-s or Cmd-v so… simply selecting the item in Launchbar's list and hitting Enter should work.
If your pasted content ends up on a line of its own (presumably above the current line) instead of in the middle of your sentence that means that the pasted text contains a new line, plain and simple. Because MacVim maps Cmd-v to P, the pasted content is pasted before the cursor: inline if there's no newline in sight, above the current line if there are newlines.
That's normal behavior.
At that point, either you find a way to clean Launchbar's content up before Cmd-v or you edit the pasted text afterward with something like ^v$y"_d<movement>P.
p and P only create new lines if the clipboard contains a newline character.
I just pasted one-line content from my clipboard into vim and it worked fine (in-line).
The issue may be with the way LaunchBar is copying to its clipboards.