Tim here again, replying in-line. > being able to store more than one thing at a time on the clipboard > with xclip. xclip/xsel only interacts with the primary (selection buffer), secondary (also sort of a lesser-used selection buffer), and the clipboard buffer. The ability to access more than one thing is what a clipboard manager like clipit is for. It retains the history and lets you recall previous selections from history. For a poor-man's clipboard history, you can dump the output of xsel/xclip to a file and the recall it later: $ xsel -ob > youtube_url.txt $ xsel -ib < my_file.txt then paste that content of "my_file.txt", and then restore the clipboard contents to what they were before $ xsel -ib < youtube_url.txt which allows you to even persist clipboard contents across reboots: $ xsel -ob > youtube_url.txt $ sudo reboot ... $ xsel -ib < youtube_url.txt You might even create a subdirectory to contain them such as ~/clip > If I press Super and select the letter t and get the terminal, > it's a terminal in gnome so xclip <somefile works fine in capturing > what's in the file to the clipboard. Correct because the clipboard is local to the machine it's running on. In this case, it's your local machine. > If I log in to this system via ssh from a pure command line shell, > I get the shell prompt and things are good but xclip <somefile > or xclip -o both cause xclip to complain about there being no > display Correct, because if you're running xclip on the remote machine that you've SSH'ed into, there's no local copy of X running there (usually) for it to access. If there is a logged-on session of X on that remote machine, you should have a ~/.Xauthority file on that machine, and you might be able to set your $DISPLAY to access the remote clipboard with xclip/xsel: me@local$ ssh me@remote me@remote$ export DISPLAY=:0.0 me@remote$ xsel This is the content of the clipboard on the remote machine where me@remote is logged in Note that xclip/xsel can work over pipes though, including SSH connections, allowing you to do things like me@local$ xsel | ssh me@remote 'cat > local_clipboard_contents_on_remote_machine.txt' to dump your local clipboard to a file on the remote machine > This certainly is better than nothing but you can't ssh > in from another system and coax the clipboard along by feeding > very-long-string-1 in, feeding that into a GUI app, then using > the command line to stuff in very-long-string-2 so you can drop > that in another box on your GUI app. I think what you're describing here is similar, so you might do me@local$ ssh me@remote ls | xsel -ib to get a listing of your home directory on the remote machine and put it on the local clipboard or me@local$ ssh me@remote 'cat data.txt' | xsel -ib In both of those cases, xsel is running locally, but taking its data from a pipe that is populated from a remote machine. > clipit is no longer being developed and diodon is what you get in > Debian, anyway, when you download clipit. Interesting. I had some recent issues with clipit on my FreeBSD daily driver (the edit-history window sometimes hangs) so it would be worth investingating diodon to see if that's fixed for me. Thanks for doing the research for me. > If I could get multiple entries to store on the clipboard, I would > be a happy camper right now since it would be possible to get > both of those awkward strings to just slide right in where they > belong. Using temporary files to store clipboard contents should give you an intermediate stop-gap solution for multiple clipboard contents, and piping contents via ssh should let you communicate them across machines. If you have trouble with either aspect, let me know which machine/OS is local, which machine/OS is remote, which machine (local or remote) is running Evolution, and which machine needs the information copied to/from it. Hoping this helps, -tim _______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/blinux-list