6 ms·

Because it runs in a terminal, and that’s how programs are supposed to behave when stdin is a tty.

fnordpiglet 4y ago
No, that’s how certain type of OS launched jobs behave, specifically pipes or daemons in foreground. There have always been programs that have very different behavior in their interaction that do not honor the job control binding. Emacs comes to mind, almost all Usenet readers, etc.
- amadeuspagel 4y ago
  Emacs is a terrific example here, and of course vim as well. "How to exit vim?" wouldn't be such a meme question if you could do it with Ctrl-C.
  - quesera 4y ago
    Emacs does nothing when you press Ctrl-C. Try it. Then do it again. It isn't "copy"! And when was the last time you tried pressing Ctrl-C in vim? It's evidently been many years. Here, I'll save you a few keystrokes: vim /tmp/sigh ^C Type :qa! and press <Enter> to abandon all changes and exit Vim
    - amadeuspagel 4y ago
      In fact this proves my point better. "How to exit vim?" wouldn't be such a meme question if people tried Ctrl-C.
      - quesera 4y ago
        This proves only that people like to complain even if their complaints are uninformed. We knew that already. Vim added Ctrl-C messaging because people complained about remembering :q. Anyone complaining about that today is just drafting off the historic humor and making a show of their ongoing ignorance.
    - fnordpiglet 4y ago
      And what does pico do? (Display cursor position) what about in control D? Terminate the input stream? Nope. It deletes the character under the cursor. Line oriented interactions ^C as break maybe makes sense. In a screen oriented termcap application I don’t think you are right.
      - quesera 4y ago
        Pico owns zero mindshare in UNIX software. Ask yourself why. This is my point.
        fnordpiglet 4y ago
        At one time it did. In fact I think exactly zero screen oriented editors I have ever used in a terminal don’t honor control c as break. Giving a statement that it doesn’t work isn’t handling it the way the terminal line oriented programs work.
        quesera 4y ago
        I would not argue that a screen-oriented editor should interrupt/exit on Ctrl-C. Certainly not without confirmation. (Note that "Break" is another key sequence entirely. If someone asks you to send a Break, you would not send Ctrl-C.) I am arguing that setting Ctrl-C to any other action (esp a very common action like Copy) in a terminal environment application of any kind, e.g. a screen-oriented editor, is a bad idea.
- quesera 4y ago
  That is how all launched executables behave, in the terminal environment. After loaded, some executables install their own handlers for Ctrl-C. None of them are copy/paste. Emacs does nothing on a single Ctrl-C, and a double Ctrl-C evokes a "this does nothing" message. Vim prints a "how to quit" message. I'm sure you can find an example of a terminal based program that does something less reasonable with Ctrl-C. I'm not sure you can find an example that treats Ctrl-C as copy. But you could certainly write one. You should expect people to complain if you do!
  - fnordpiglet 4y ago
    Rather I think there’s a distinction between line oriented and screen oriented. I don’t think screen oriented programs tend to honor the line mode meh bindings. When you press control-d in top do you expect it to close the terminal?
    - quesera 4y ago
      Ctrl-D means "End of transmission", which is appropriate to exit a program which expects to receive input. A process monitor like top isn't oriented toward input, particularly, so I would not expect Ctrl-D to do anything. And it does not. By the way, Ctrl-D does not close the terminal either. It tells the shell that you're finished sending input, which means it has no more work to do and should exit. If you have jobs running in the background, it will warn you first (default config). If the shell exits, and it was the only thing running in the terminal, the terminal may then decide to close itself. Some do, some do not. Back to Ctrl-C though, using your example of top as a screen-oriented program: when you press Ctrl-C in top, it interprets the input as Interrupt, and ... exits! Just like a user in a terminal environment would expect. :)
      - fnordpiglet 4y ago
        Yes, I’m aware of what it does. But do you have any screen oriented programs that treats ^D as a signal to close stdin? You are right, it does exit on ^C. I picked it as an example of something that seems compliant but doesn’t actually behave like a line oriented program as a screen oriented program.

No, that’s how certain type of OS launched jobs behave, specifically pipes or daemons in foreground. There have always been programs that have very different behavior in their interaction that do not honor the job control binding. Emacs comes to mind, almost all Usenet readers, etc.

amadeuspagel 4y ago
Emacs is a terrific example here, and of course vim as well. "How to exit vim?" wouldn't be such a meme question if you could do it with Ctrl-C.
- quesera 4y ago
  Emacs does nothing when you press Ctrl-C. Try it. Then do it again. It isn't "copy"! And when was the last time you tried pressing Ctrl-C in vim? It's evidently been many years. Here, I'll save you a few keystrokes: vim /tmp/sigh ^C Type :qa! and press <Enter> to abandon all changes and exit Vim
  - amadeuspagel 4y ago
    In fact this proves my point better. "How to exit vim?" wouldn't be such a meme question if people tried Ctrl-C.
    - quesera 4y ago
      This proves only that people like to complain even if their complaints are uninformed. We knew that already. Vim added Ctrl-C messaging because people complained about remembering :q. Anyone complaining about that today is just drafting off the historic humor and making a show of their ongoing ignorance.
  - fnordpiglet 4y ago
    And what does pico do? (Display cursor position) what about in control D? Terminate the input stream? Nope. It deletes the character under the cursor. Line oriented interactions ^C as break maybe makes sense. In a screen oriented termcap application I don’t think you are right.
    - quesera 4y ago
      Pico owns zero mindshare in UNIX software. Ask yourself why. This is my point.
      - fnordpiglet 4y ago
        At one time it did. In fact I think exactly zero screen oriented editors I have ever used in a terminal don’t honor control c as break. Giving a statement that it doesn’t work isn’t handling it the way the terminal line oriented programs work.
        quesera 4y ago
        I would not argue that a screen-oriented editor should interrupt/exit on Ctrl-C. Certainly not without confirmation. (Note that "Break" is another key sequence entirely. If someone asks you to send a Break, you would not send Ctrl-C.) I am arguing that setting Ctrl-C to any other action (esp a very common action like Copy) in a terminal environment application of any kind, e.g. a screen-oriented editor, is a bad idea.
quesera 4y ago
That is how all launched executables behave, in the terminal environment. After loaded, some executables install their own handlers for Ctrl-C. None of them are copy/paste. Emacs does nothing on a single Ctrl-C, and a double Ctrl-C evokes a "this does nothing" message. Vim prints a "how to quit" message. I'm sure you can find an example of a terminal based program that does something less reasonable with Ctrl-C. I'm not sure you can find an example that treats Ctrl-C as copy. But you could certainly write one. You should expect people to complain if you do!
- fnordpiglet 4y ago
  Rather I think there’s a distinction between line oriented and screen oriented. I don’t think screen oriented programs tend to honor the line mode meh bindings. When you press control-d in top do you expect it to close the terminal?
  - quesera 4y ago
    Ctrl-D means "End of transmission", which is appropriate to exit a program which expects to receive input. A process monitor like top isn't oriented toward input, particularly, so I would not expect Ctrl-D to do anything. And it does not. By the way, Ctrl-D does not close the terminal either. It tells the shell that you're finished sending input, which means it has no more work to do and should exit. If you have jobs running in the background, it will warn you first (default config). If the shell exits, and it was the only thing running in the terminal, the terminal may then decide to close itself. Some do, some do not. Back to Ctrl-C though, using your example of top as a screen-oriented program: when you press Ctrl-C in top, it interprets the input as Interrupt, and ... exits! Just like a user in a terminal environment would expect. :)
    - fnordpiglet 4y ago
      Yes, I’m aware of what it does. But do you have any screen oriented programs that treats ^D as a signal to close stdin? You are right, it does exit on ^C. I picked it as an example of something that seems compliant but doesn’t actually behave like a line oriented program as a screen oriented program.