I've just used alias c=clear in my .bashrc and never looked back. Not even Ctrl+L feels as convenient as c+Enter

Ctrl+L works when a program is running. Clear does not.

> Ctrl+L works when a program is running. Clear does not.

I can't see how because ctrl+l is a $SHELL / readline shortcut rather than one defined in the terminal emulator. Once you run a program you're forking STDIN control to another process so you'd have to wait for the $SHELL / readline prompt again just like you would if you typed a command / function / alias into the command prompt.

lub

Is ctrl+c handled; by the terminal emulator?

ctrl+l allows to clear when the prompt is non-empty, maybe parent poster meant that

laumars

I'm not 100% sure how ctrl+c (and ctrl+z) are handled but I do know they're edge cases because they're managed by the kernel and are not re-definable.

Pete_D

The terminal can optionally catch some characters and convert them to signals. By default, ^C sends SIGINT, ^\ sends SIGQUIT, and ^Z sends SIGTSTP. Programs can disable that for their own purposes (stty -isig) and you can rebind them to other characters if you want (stty intr, stty quit, stty susp) but I don't know why anyone would these days.

hnlmorg

In Linux and UNIX you enable or disable use of ctrl+c (effectively setting the tty into a raw mode) via syscalls against the tty file descriptor - it is not handled by the terminal emulator at all (in fact if you read the man page for `stty` you'd see it's changing the your terminals fd and not the terminal emulator).

Sure, theoretically terminal emulators could capture and even rebind those keys via the APIs of whatever graphical toolkit they're built in....but if you wanted to rebind SIGINT to another key in the terminal emulator, that terminal emulator would still have to transmit ^c to the tty.

As for rebinding those keys in the kernel, Linux simply doesn't support doing that and nor does it support binding other keys to different signals. In fact I've tried to do this on a tool I was working on to emulate BSD's SIGINFO in Linux (turned out not to be possible) as as well part of the job control (SIGSTSP et al) support in my $SHELL (https://github.com/lmorg/murex).

This is also why you can throw signals over an SSH (or other remote shell) session when the terminal emulator itself would have no knowledge of the commands running on the remote host.