Don't touch my clipboard

If you're using Readline (most Bash or similar shells do), then C-x C-e will invoke the editor, and you can paste the output into that.

Pray for no escape, bang, or control sequences.

(Alternatively: "r! cat -D" will read into a vim session.)

Examine the output, trim the unwanted / dangerous bits, and run (or save to a file/script).

Since I run what are ... generously ... considered "bash one-liners" all the time, that key sequence is locked into my muscle memory. It's a convenient way to invoke an editor immediately and run code from it.

> I work around this by cut & pasting single characters around to fix up the missing accent characters.

Let me save you some time in the future. You did not identify the OS and language/script you have trouble with, so my answer has to be kinda generic.

First have a look whether your OS keyboard settings or a third party provides an en_US-101 compatible logical layout that adds more accented characters (typically accessed with right Alt¹) or extra modifier keys² (in addition to acute, grave, tilde), then install it and memorise the characters you need. Oftentimes, this is easy because it's mnemonic, e.g.

    AltGr+l → ł
    AltGr+d → ð
    AltGr+o → ø
    dead_tilde N → Ñ
    dead_double_acute o → ő
    dead_circumflex dead_hook O → Ổ

If that's not sufficient or too cumbersome, look into compose key³. That system is user extensible, more powerful because it provides not just accented characters, and to the most part has better mnemonics; e.g.:

    compose U G → Ğ
    compose " y → ÿ
    compose a e → æ
    compose t , → ț
    compose v z → ž
    compose I . → İ
    compose u o → ů
    compose c | → ¢
    compose . . → …

¹ http://enwp.org/AltGr_key ² http://enwp.org/Dead_key ³ http://enwp.org/Compose_key

There are already (at least) two clipboards in many platforms.

X11/Xorg has the primary and secondary selections.

MacOS has ... whatever it's got.

A key problem with this is that the feature is covert, latent, poorly discoverable, and causes unexpected behaviours. Even presumably advanced users (myself, you, other HN readers) are poorly aware of this. Imagine trying to explain to your nontechnical Aunt Tilly or Uncle Kamlesh about these "different clipboards which treat what you've copied differently and access through this funky interface"?

We've been through the blacklisting argument numerous times: spam, viruses, adware, malware, spyware, browser adblocking, etc.

It ... ultimately doesn't scale. The black-hat namespaces are too large, and treating as TOFU eventually proves untenable.

Advanced features -- anything beyond rendering basic HTML, and I'd be quite prepared to argue for a very limited subset of that -- should be expressly prohibited unless enabled.

The trick is to make enabling reasonably painless and consequence-free (e.g., enable into a sandbox). There are still the problems of users gratuitously enabling anything and everything (especially when prompted through website notifications, pop-ups, phishing and vishing social engineering attacks, etc.), as well as the problem of largely invisible second and higher-order effects.

But the key is to cut down on the effectiveness of such methods, to impose costs on websites for employing them, and to make black-hat attacks through these too expensive by reducing the herd susceptibility to the attacks (the unbocking would have to occur on a one-at-a-time case-by-case basis, e.g., it's expensive and has limited scalability).

I don't think we'll actually see this for another 5-10 years (my usual sane-suggestion take-up lead time, it seems), but It Would Certainly Be Nice To See.

Copying from HTML tables is already sane.