3 ms·

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

Jtsummers 4y ago
https://en.wikipedia.org/wiki/IBM_Common_User_Access 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?
- permo-w 4y ago
  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
  - deleted 4y ago
    [deleted]
  - floydnoel 4y ago
    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?
    - permo-w 4y ago
      I don't believe so. why? because those shortcuts are the standard across practically every program that is not a terminal
      - drekipus 4y ago
        > 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.
        deleted 4y ago
        [deleted]
rlpb 4y ago
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.
- adhesive_wombat 4y ago
  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.
- permo-w 4y ago
  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
  - thesuperbigfrog 4y ago
    >> 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.

https://en.wikipedia.org/wiki/IBM_Common_User_Access 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?

permo-w 4y ago
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
- deleted 4y ago
  [deleted]
- floydnoel 4y ago
  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?
  - permo-w 4y ago
    I don't believe so. why? because those shortcuts are the standard across practically every program that is not a terminal
    - drekipus 4y ago
      > 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.
      - deleted 4y ago
        [deleted]

rlpb 4y ago

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.

adhesive_wombat 4y ago
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.
permo-w 4y ago
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
- thesuperbigfrog 4y ago
  >> 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.