31

Is there any way to remove ^C when you hit CTRL+C in the shell include with Red Hat Enterprise Linux 6 ("Santiago")? I have permission to edit my own .bash_profile.

mattdm
  • 40,245
Fede Gold
  • 421

3 Answers3

34

Edit (or create) your ~/.inputrc file. Add a line saying

set echo-control-characters Off

This will instruct the GNU Readline library (which Bash uses) to not output (echo) any control characters to the screen. The setting will be active in all new Bash sessions thereafter (and in any other utility that uses the Readline library).

Notice that if your Unix system comes with a system-wide configuration file for the Readline library (usually /etc/inputrc), then your personal configuration file will need to include that file:

$include /etc/inputrc
set echo-control-characters Off

Another alternative is to make a personal copy of the system-wide configuration file and then modify that.

Kusalananda
  • 333,661
  • Hi , I tested this and its working fine but when I interrupt a running bash command it didnt worked, for example sleep 180 and press CTRL+C – Raja G Dec 30 '16 at 13:42
  • @Ten-Coin It will only work if the command uses the Readline library unfortunately. – Kusalananda Dec 30 '16 at 13:44
  • 1
    If ~/.inputrc does not already exist then simply creating the file may lose some existing settings. In my case I first noticed that ctrl+left and ctrl+right had stopped working. The fix was to start my ~/.inputrc with this line $include /etc/inputrc. It is also possible to just cp /etc/inputrc .inputrc and edit as desired. – kasperd Dec 31 '16 at 10:18
  • 2
    @kasperd Good point! I was not aware that adding a personal configuration file would disable the reading of the system-wide configuration file (my system doesn't have one). I will update my answer. – Kusalananda Dec 31 '16 at 10:30
24

Try the following:

stty -echoctl

For an explanation see this great and detailed post from Stéphane Chazelas which also explains some other stty features.

If you want to make that change permanent (and you are using bash as implied in your question) then it's best to put into your .bashrc as noted by jlmg in the comments (so it applies to all interactive shells).

Community
  • 1
phk
  • 5,953
  • 7
  • 42
  • 71
  • 1
    +1 In contrast with the readline solution, this should work for most if not all things running in the terminal. – JoL Dec 30 '16 at 23:02
  • 1
    One should probably mention that it won't work on all terminals if put in .bash_profile as that file is only parsed by login shells. It should be put in .bashrc instead, so it's read by all interactive invocations. – JoL Dec 30 '16 at 23:08
  • @jlmg I would consider that to be a drawback. Personally I would prefer behavior identical to bash version 2 or 3 were you could still see if a running command was interrupted by ctrl-c. – kasperd Dec 31 '16 at 00:36
  • 1
    Won't this still echo the raw 0x03 byte, which may theoretically be interpreted by some terminals? It will also have side effects if you do things like running a non-readline command, pressing an arrow key will move the cursor on the screen rather than showing ^[[A – Random832 Dec 31 '16 at 02:32
  • @kasperd Well yes, but the OP didn't specify any restriction. That's why I consider this answer to be the best. Personally, I wouldn't want my ^C to ever be hidden either, neither when running a program under the shell nor on the command line. Looking back at commands I've run and seeing a ^C at the end of a command line let's me know I didn't actually run it (probably because I realized that I needed to run something else first). That's important info for me. – JoL Dec 31 '16 at 19:46
  • 1
    @Random832 +1 You're right. I guess that setting is just badly named; it doesn't control the echoing of control characters but rather their translation to printable characters before echoing. To prevent that side effect, you'd have to stty -echo too. That of course is going to prevent the echoing of everything else as well, which probably makes this answer a no-go if all you wanted was to hide the ^Cs. – JoL Dec 31 '16 at 20:11
  • 1
    @jlmg If the ^C was always at the end I might agree with you. But the ^C will be printed where ever the cursor was, which can overwrite a pair of characters anywhere in the command. That means if you need to copy-paste parts of that command you may end up with something mangled. And the ^C is not as easily recognized when looking over the terminal as it would have been if it was at the end of the command. – kasperd Jan 01 '17 at 02:14
  • Hi folks. This solution seems to give me trouble when I use a system that submits sge and/or slurm jobs through the paramiko python package. Just noting here in case someone else spends a few days trying to figure out why their jobs won't submit. The .inputrc solution above does not give me any problems. – lonestar21 Aug 01 '19 at 16:40
2

If you're trying to find a configuration that will allow normal echoing (including echoctl) and just silence the echoing of signal-generating characters, and you're sure it should be possible because you've seen it work that way before...

You probably have seen it that way. But it's no longer possible, because of this commit:

commit ec5b1157f8e819c72fc93aa6d2d5117c08cdc961

Turn on INTR/QUIT/SUSP echoing in the N_TTY line discipline (e.g. ctrl-C will appear as "^C" if stty echoctl is set and ctrl-C is set as INTR).

Linux seems to be the only unix-like OS (recently I've verified this on Solaris, BSD, and Mac OS X) that does not behave this way, and I really miss this as a good visual confirmation of the interrupt of a program in the console or xterm. I remember this fondly from many Unixs I've used over the years as well. Bringing this to Linux also seems like a good way to make it yet more compliant with standard unix-like behavior.

If you remember fondly how Linux used to not echo that ^C, the only way to get the old behavior back is to patch your kernel. In recent versions, the echoing of signal-generating characters is at lines 1215-1218 of drivers/tty/n_tty.c.