Clipboard size limit #3937
Describe the bug
Stuff copied to the clipboard via
Alternative, in Bash:
seq 1 914979 | printf "\e]52;c;%s\a" "$(cat - | openssl base64 -A)" # sequence gets copied seq 1 914980 | printf "\e]52;c;%s\a" "$(cat - | openssl base64 -A)" # sequence does not get copied
The text was updated successfully, but these errors were encountered:
Doesn't 8 MB strike you as a little bit small? I'm typing this on a laptop with 2,000x that amount of physical RAM.
And they're not really "random" programs though, are they? They are programs that I chose to run, presumably because I trust them. Consider programs on the local machine too: they also could allocate arbitrary amounts of memory and "DOS" my machine, but I chose to run them.
On Mon, Aug 16, 2021 at 03:43:35AM -0700, Greg Hurrell wrote: Doesn't 8 MB strike you as a little bit small? I'm typing this on a laptop with 2,000x that amount of physical RAM.
No it doesnt. You probably have a browser running that is using 90% of that RAM :) On a more serious note, what limit would you suggest?
And they're not really "random" programs though, are they? They are programs that I chose to run, presumably because I trust them. Consider programs on the local machine too: they _also_ could allocate arbitrary amounts of memory and "DOS" my machine, but I chose to run them.
While I certainly do trust the software on my local machine, I do not trust the software on random machines I ssh into.
It could be logs, the output of a program, a debugging session in a REPL etc... I regularly want to capture a large amount of text from the terminal for sharing (for example, I might paste it into a private Gist). And this isn't on "random" machines. It's on machines that I regularly do development work on; if the systems are compromised, then the ability to inflate my local clipboard's memory footprint are the least of my concerns.
I just plucked the 10x figure out of the air because any number I say is going to be abritrary, but what I don't want is thinking that I've captured all the information when I actually haven't because the limit is applied silently. For example:
In this scenario, I think I've captured two distinct sets of data, but I've actually captured the first one twice (because the second one never overwrote the previous clipboard contents), and because we're talking about logs which might look the same at first glance, I might not notice the information loss. And then I disconnect from the server, and the information is gone...
Now, I know I could redirect this kind of thing to a file (if I have the presence of mind to do that before running the command that generated the output), and then
As noted here: wincent/clipper#26 I still don't have a good story for making Clipper do its thing both locally (when I am sitting in front of my Linux box) and remotely (when I am SSH'd into it from my laptop). As that issue describes, you _can_ use the OSC 52 support in kitty to get stuff into the clipboard transparently, but, as explained here: kovidgoyal/kitty#3937 it has a hard cap on the size that you can copy this way, which makes me hesitant to fully rely on it. You can customize the limit with `clipboard_max_size`, but the fact that there is a limit at all leads me to analysis paralysis... how to set an arbitrary quantity like that? And even if I do get everything working with kitty, I'm only using that on my personal machines, not my work machine, so if I ever need to SSH in from my work machine to the Linux box to do something (eg. grab some changes to my dotfiles or something) I'll be left with inconsistent support. I've gone back and forth on this in the past, see: commit bf75f40 Date: Sun Aug 15 10:57:49 2021 +0200 refactor(dotfiles): [demo] teach `clip` to use OSC 52 escape sequence commit ef94ece Date: Sun Aug 15 11:02:57 2021 +0200 chore: revert "refactor(dotfiles): [demo] teach `clip` to use OSC 52 escape sequence" commit c85890b Date: Sun Aug 15 11:17:03 2021 +0200 refactor(dotfiles): switch back to using OSC 52 for `clip` when in Kitty