Ask HN: Why do terminals insist on interfering with copy and paste? | Hacker News Reader

Ask HN: Why do terminals insist on interfering with copy and paste?

14 pointspermo-w28 comments

I appreciate that these terminals are often old and have very entrenched norms, but co...+c and co...+v have been standard in windows and mac for a very long time, and they are expected behaviour

even if there's a huge history of this, which I'm certain there is, I find it as just as irritating as the apps that don't actually close when you click the close button. why not perform the expected user behaviour, and leave the alternative as a setting? there are 24 other letters to choose from for keyboard interrupts and the rest

linux's ctrl-shift-c/v isn't so bad, but I still have to ask why? for such common, non-dangerous operations, why mess with the expected behaviour?

I'm guessing mostly the explanation is that they did it in the first place when the rules weren't so concrete, and development tools like this tend to prioritise legacy users over new?

View on HN

This is one of the reasons I love my Mac, though it’s total happenstance it works this way.

Since the Mac uses Command-c/v it doesn’t interfere with the standard Unix terminal’s Control functions. But you can easily trigger the Mac’s functions (such as Commamd-f for find) without worry.

It sidesteps the problem Windows users have that used to frustrate me too.

Edit: I looked it up. Early Macs didn’t even have a control key. It was added later for terminal client compatibility.

I wish they'd add a real goddamned Delete key for common-sense compatibility.

My keyboard has a delete key. Do you mean on laptops?

Their full keyboards have it in the usual spot, laptops and the smaller keyboards have a "delete" key that's actually backspace. fn + "delete" gives you actual delete.

Laptops and even the small keyboards that they're shipping with some desktops.

It's ridiculous.

Control-C has been the ‘break’ key for serial consoles since the 1970s so it is the GUI cut and paste that is new.

I believe that is true, but that doesn't automatically make it the sensible choice for ctrl-c

https://en.wikipedia.org/wiki/IBM_Common_User_Access <- origin of C-c/C-v and other shortcuts for copy/paste and related activities.

The date on that publication is 1987. So what you're asking for is, why didn't people in the 1970s anticipate this future de facto standard?

what an odd assumption

I'm suggesting that the de facto standard behaviour should be respected, or made opt-out. what people did or thought in the 1970s isn't relevant to that

The standard behavior, is for C-c to send SIGTERM. You’re advocating to change that standard to a new standard. Why should your preference take priority over decades of standardization? Shouldn’t the old standard be respected, or made opt-out?

I don't believe so. why? because those shortcuts are the standard across practically every program that is not a terminal

> because those shortcuts are the standard across practically every program that is not a terminal.

Shift + insert works far more ubiquitously.

C-c doesn't work on electron apps for me.

You'd have to break behaviour for all experienced sysadmins then. I don't see why these users are "legacy", when terminals exist exactly for this kind of purpose. Personally I use Ctrl-C for SIGINT far more than I use Ctrl-Shift-C for copy. So why would I want it the other way round?

And what about Ctrl-Z, Ctrl-D and Ctrl-A, all of which I use regularly? Are you going to require these to have Shift added too? What about all the other control codes? Or are you going to be inconsistent and have special behaviour just for C, X and V?

Whichever way, you'd end up with a configuration setting for your claimed "legacy" behaviour. Then there will be two ways to do things, and that'll be confusing whenever someone has to use someone else's terminal, or give someone instructions to help them.

You can also issue the relevant stty command to remap the interrupt control key in your .bashrc.

Or configure or modify your terminal to remap the keys before it gets to the TTY driver.

they're legacy by definition of being pre-existing users. if you're used to that setting, you have a legacy of using it

a new user would not expect git bash to have shift-insert as paste, and that is an unnecessary inconvenience, especially considering that git bash is more the rule than the exception in doing this, with a variety of different routes to the same goal

I think they should be opt-in instead of opt-out or forced. standards save time and energy and they should be respected, especially in something so common, especially if the legacy alternatives are so easily maintained

>> standards save time and energy and they should be respected, especially in something so common, especially if the legacy alternatives are so easily maintained

In a terminal the standard is for Ctrl-C to send SIGINT to the foreground process.

If a terminal emulator did not follow this standard behavior, I would not use it.

I keep shutting down my processes with ctrl+c all the time. Then for a moment I become extra careful to hit ctrl+shift+c instead, so next when I open the browser and try to copy something I end up opening the developer tools instead. To make matters worse, I had a mouse with a broken mouse wheel when I was a teen. The middle click still worked, so I learned to rely on autoscroll a lot. So I had to disable the middle mouse click paste because I kept pasting my clipboard everywhere. I hate what I have become.

Not being able to remap it disable the shortcut developer tools in Firefox is really annoying.

Eventually I settled on intercepting it, only in Firefox, with AutoKey.

I think the simple answer is:

- Ctrl-C was first, existing before GUIs had been invented.

- Ctrl-C isn't really a terminal thing. There are things you can press on a keyboard the terminal will interpret, but it passes Ctrl-C through.

- Things that run in terminals rely on this. It's an easy way to send SIGINT.

- GUIs came onto the scene, and in Windows Ctrl-C/X/V was copy/cut/paste.

- People built terminal emulators (xterm) for UNIX GUIs, and didn't have this conflict because they didn't use Ctrl-C/X/V for copy/cut/paste.

- Slowly UNIX terminal emulators and Windows GUI standards started to occupy the same space (GNOME, KDE, WSL), which led to this conflict.

So your perspective of Ctrl-C/X/V = copy/cut/paste is expected behavior isn't incorrect, but it's also not incorrect that many (more?) people expect Ctrl-C to send SIGINT in a terminal. You're experiencing the conflict that everyone else is, you'd just make concessions in a different way.

To that end, this is configurable in many terminals: Konsole [0], Gnome Terminal [1], xterm [2], URxvt [3].

[0]: https://old.reddit.com/r/kde/comments/quirya/how_to_use_ctrl...

[1]: https://askubuntu.com/questions/53688/making-ctrlc-copy-text...

[2]: https://unix.stackexchange.com/questions/339160/enable-ctrlc...

[3]: https://stackoverflow.com/questions/39884093/rebinding-copy-...

As others have noted, the Macintosh has always avoided this by using the Command key.

I really wish we could create additional OS level modifier keys like Shift, Control, Alt, Window/Command. Such functionality would go along way to solving this issue and maintaining the normal key bindings. This would allow me to add macOS style keybindings on Windows and Linux.

I know about Kinto. And have created my own Windows 1000 line AHK macro along with a fully programmable hardware keyboard to mostly get the key bindings I want. However, being able to add my own OS level modifier keys would make this so much easier and better

I have been using xremap to achieve Mac-like shortcuts on Linux. It uses uinput to intercept and emulate keystrokes and can be DE-aware to recognize applications in focus for app-specific shortcuts.

*nixes have superior copy-paste functionality using mouse selection + scroll wheel click or shift+insert. Ctrl-c Ctrl-v is really bad and clunky in comparison.

"I find it as just as irritating as the apps that don't actually close when you click the close button"

Yep, that's a pillar of the Mac experience.

I suppose at least in apple products it's somewhat the norm. also, that typo is awful. deepest apologies for that ;)

Hahah NP

Reply on news.ycombinator.com