Por que o ctrl + c foi escolhido para matar um processo? [fechadas]

Question

Estou ciente de porque ctrl+c mata um programa; Estou mais interessado na história do porquê "c" foi escolhido sobre outras letras, dado que (aparentemente) não tem significado semântico.

Se alguém souber a história por trás disso (e outros como ctrl+d para EOF), isso seria incrível.

    

Answer 1

Originalmente publicado em Unix.stackexchange.com , mas não consigo fechar vote para essa resposta, então esta é uma cópia:

The “kill” meaning of Ctrl+C is very old, I think even older than Unix. Wikipedia traces it back to TOPS-10, which would date it from the late 1960s. The article explains why Ctrl+C was a reasonable choice: in ASCII, which was published in 1963, the corresponding character is ETX, end-of-text. Lacking a character meaning “stop”¹, a character meaning “this segment of input is over” was a reasonable choice to mean “stop the current processing”.

The “copy” meaning of Ctrl+C comes from Xerox PARC, the inventors of copy-paste in its modern form (and most other fundamentals of graphical user interfaces). I don't know exactly when that was, but it must have been the late 1970s. This thread on User Experience Stack Exchange discusses the choice of key bindings; C for copy makes a lot of sense.

There was little reason for PARC to reject Ctrl+C for copy on the basis of the existing meaning in TOPS-10 and Unix terminals. Operating systems and applications were more diverse then, and far fewer people used computers; there was no opportunity nor call for a single standard for key bindings across all applications. Other uses for Ctrl+C in popular applications include page-down in WordStar² and mode-specific command in Emacs. All of these were designed independently, for applications with often different requirements, running in different environments.

You can configure the terminal key bindings with the stty command. The terminal bindings are active when the terminal is in cooked mode³. For example the command stty intr ^G sets the character that sends a SIGINT signal to Ctrl+G instead of Ctrl+C. The ^G character is BEL in ASCII; when sent to a terminal, it means “ring the bell”. It's the character that Emacs uses for “interrupt the current operation” (rationale: the application sends BEL to the user via the terminal to interrupt the user; the user sends BEL to the application via the terminal to interrupt the application). It doesn't have a standard meaning when sent to a terminal.

Most shells provide line editing features, so they set the terminal to raw mode. So do full-screen text mode applications. You may need to configure these applications to recognize Ctrl+G instead of Ctrl+C, and some may have non-configurable key bindings. So changing the interrupt character may or may not be practically doable depending on which applications you use.

Another approach could be to configure your terminal to change the byte sequence that it sends for the Ctrl+C keychord, or make it send nothing and instead perform a copy operation. You would also choose a different keychord to send Ctrl+C (if you have a non-laptop PC keyboard, you could use the out-of-the-way Pause/Break key). Not all terminals can be configured in this way.

¹ _{Ctrl-S (XOFF) means stop, but it's addressed to the terminal, not to the application.} ² _{Next to Ctrl+X for next-line, with Ctrl+E and Ctrl+R for previous-line and page-up; these keys were chosen due to their placement on a QWERTY keyboard.} ³ _{Nitpick: cooked mode is a set of terminal settings, including the interpretation of several characters including one that sends an interrupt signal.}