the full monty: alias c='echo -e "\033c" ; stty sane; setterm -reset; reset; tput reset; clear'

doesn't only clear the screen, but also escape any "broken" terminal configuration such as output of a binary on the tty

One can spot cargo cult command-line use when two pairs of the commands overlap functionally, and another triplet is the same program by different names.

Also note that RIS is a bad idea, discouraged since 1983 I recently discovered, although DEC did not think to tell people outside DEC this for half a decade. Use DECSTR.

setterm does not work on macOS. I find reset(1) working fine. It already does clear, too.

One of these days, someone will take my portable setterm, which compiles fine on FreeBSD, and compile it on MacOS. (-:

* http://jdebp.uk./Softwares/nosh/guide/commands/setterm.xml

> Ctrl+L feels as convenient as c+Enter

I learned to hit Ctrl with my palms, and never looked back. Do you use your pinky? If so, I agree c+Enter is more convenient than ctrl+L.

It never even occurred to me to do that but trying it now, I don't think it's feasible for my hands. Either my palm mashes CTRL, ALT, and CMD (and sometimes FN and Shift) or I have a super awkward angle to get to the C key. It seems much easier to just drop my pinky down for half a second.

EDIT: After a suggestion from another user, I just remapped my Caps Lock to CTRL. That seems a lot easier to deal with. I'll try that for a bit and see how it goes.

I use my left pinky to press Ctrl, and I use the right hand for L (index finger), so it makes no difference whether I press L or Enter using my right hand. I would probably use the right pinky for the Enter key. Works either way to me, but I am used to pressing Ctrl-L (left pinky for Ctrl, right index finger for L).

I have mapped capslock to ctrl (esc if used without modifiers) which made ctrl+L extremely comfortable for me.

I don’t quite understand why. With one hand or two?

Left pinky for ctrl (capslock) and right ring finger for L. Works incredibly well for my hands (a quality keyboard helps too). The capslock mapping is obviously meant for vim but works great for many shortcuts like this (ideally there would be a second ctrl/esc and other modifiers to operate with right pinky comfortably, starting my first custom build soon...).

Now you have Ctrl on home row, instead of two rows down.

On a standard PC keyboard, I just use my palm to hit Ctrl (part of why I detest keyboards where Left Ctrl is not at the bottom left corner.

Some smaller keyboards (including laptops) make the control key small or add an "Fn" key to the bottom-left corner (Apple does this). I tend to hit Ctrl with my left hand, so mapping caps lock to Ctrl makes it more reliable to hit.

im reminded of this: https://imgs.xkcd.com/comics/workflow.png

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.

Is ctrl+c handled; by the terminal emulator?

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

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.

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.

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.

Good point, I should have said TTY driver (all my information is from half-remembered reading of https://www.linusakesson.net/programming/tty/index.php, any mistakes are my own).

With respect to rebinding, what is "stty intr ^D" doing if not rebinding the interrupt character to ^D?

I feel your pain about not having SIGINFO though.