I love the "It's harmless with a terminal emulator". I (obviously) get what they're saying, but you'd think making millions of people waste 3 seconds of their lives every time would be considered at least a modicum of harm.
reset wouldn’t be used used by millions of people and most of
those who do use wouldn’t be using it regularly either.
reset should be a last resort. If you need to use it then something else has gone wrong and thats what needs to be fixed.
I’m all for modernising our terminal but in this instance we are talking about a last resort command taking 3 seconds longer than needed just in case some of some edge case scenario occurs. So 3 seconds is definitely not harmful.
I think in this case it's a bit exaggerative, but this isn't the only example--the mentality is pervasive throughout software engineering: It's OK to sacrifice the user's time (through poor software performance, unnecessary network calls, mutexes and synchronization, and deliberate delays) for developer comfort, or if it means we can go fix something else, or if it's just a really hard problem... Hey, user's time doesn't cost us and they can always wait...
And it adds up: 100ms here, 200ms there, times millions of users, times dozens of times per day the issue happens, and it's no wonder our 2024-era supercomputers still feel about as slow as my 2004 Windows XP machine.
I completely agree. But in this case ‘reset’ isn’t the problem. It’s that terminal emulators don’t surface an easier and more standardised way to clear their scrollback history. That’s the thing that needs fixing.
Sadly there isn't on Linux. There is on Mac - Ctrl-K. But for some reason nobody on Linux has realised how useful it is. It's actually even better than `reset` because it works at any time.
I think you're conflating SHELL with TERM because the OS has nothing to do with what hot keys your terminal emulator supports (the OS wouldn't dictate hot keys available for shells either, but popular Linux distros don't tend to default to Zsh like macOS does).
A terminal emulator is the software application you use to bring the command prompt up. So a terminal emulator is operating system agnostic.
Granted there are some macOS only terms out there like iTerm2 and Apples own Terminal. Just as there are terminals that haven't (as far as I'm aware) been ported to macOS, like xterm. But there's plenty of cross platform terminal emulators too, in fact most are cross platform.
I'm not conflating anything. On Mac you can press Ctrl-K in any terminal emulator and it will clear the terminal and scrollback. On Linux no terminal emulators support this (except Kitty it turns out - as mentioned in the other comment).
Sadly Kitty is very bare-bones. Not really for me. And I can't choose to use Kitty in VSCode.
Care to elaborate? I had an impression that it's a pretty complete piece of software. I've been driving it daily for more than 1½ years, and I'm pretty happy with it.
Well the first two things I tried that are present in pretty much all software - scroll bar and Ctrl-F to find, did not exist. There's no menu bar at all in fact.
I didn't even realize, I don't see a need for it anyway.
> Ctrl-F to find, did not exist
That's because Kitty has something much better:
> Sometimes you need to explore the scrollback buffer in more detail, maybe search for some text or refer to it side-by-side while typing in a follow-up command. kitty allows you to do this by pressing the ctrl+shift+h shortcut, which will open the scrollback buffer in your favorite pager program (which is less by default).
> There's no menu bar at all in fact.
Which is a big plus. Emacs has a menu bar (and a toolbar), and I obviously turn them off, because they take up screen real estate.
That shortcut opens HISTORY, hence it is ctrl+shift+H. And if the terminal emulator used up ctrl+f to implement find, it would mean that no terminal program could use ctrl+f to implement find. Maybe next time before you try to imply other people dont know UX, pause, and consider if you know what you are talking about. Incidentally, using the term UX itself, generally is a good signal that the person that is using it doesnt have a clue what they are talking about.
And ctrl+shift+f is the same as ctrl+f for you? The point of using "identical" keybindings is to ease discoverability across programs. ctrl+shift+f and ctrl+f are not identical and therefore there is no point to doing that.
And pretty much anyone that has to deal with internet commenters using the term UX thinks that, not just me.
Ctrl+Shift+F is commonly "find in all files" so it's a logical shortcut to try. In addition, adding Shift to a shortcut to get around this exact problem is also common. For example Ctrl+Shift+C/V are common copy/paste shortcuts in terminal emulators on Linux.
> reset should be a last resort. If you need to use it then something else has gone wrong and thats what needs to be fixed.
Er, my comment was exaggerative? (edit: fixed typo)
I use reset all the time, it's not "last resort" by any means. It... clears the screen and scrollback buffer. If you're the kind of person who keeps 150 tabs open then I guess I can see why you wouldn't see the value in cleaning the screen up frequently, but clearing the terminal is a pretty frequent and useful operation for other folks.
Fwiw parent comment currently says exaggerative, not aggressive.
Why wouldn't you use "clear" for that, or Ctrl+L? "reset" does a lot more, you use it when you've accidentally written a binary to your terminal and triggered a bunch of terminal modes.
I guess clear wouldn't clear the scroll buffer, is that the main reason?
I think that's a libvte pecularity (used among others by the Gnome and XFCE terminal emulators), which upon entering <clear> (or pressing CTRL+L) just scrolls up until the screen seems to be empty. Make sure you set terminfo correctly, ie. E3=ED3, so that it clears the text and scroll buffer.
On any non-libvte using terminal emulator, eg. xterm, you can use CTRL+L to clear the text area and ALT+CTRL+L to clear the text area and the scroll buffer.
If you need reset(1) to clear the screen and scrollback buffer all the time (it shouldn’t clear the buffer btw, don’t know why you think it does if you really do it all the time), consider using your terminal emulator’s native keyboard shortcut, it’s faster to type, faster to run, you can do it at any time without the shell yielding control back to you, and it doesn’t pollute the shell history.
If your terminal emulator doesn’t even have that, I suggest switching to a better one.
I hope you realize you’re doing something really suboptimal here.
Edit: Saw your other comment and apparently you don’t even use reset(1), just your own function (which is still suboptimal like I said). WTF is with all the arguing then.
No it wasn’t. But I also said exaggerative not aggressive.
> I use reset all the time, it's not "last resort" by any means. It clears the screen.
That’s what ‘clear’ is for.
Reset is intended to do more than just clear the screen. It’s intended to reset, as the name suggests, the entire terminal. The idea being it’s got itself into some kind of unknown state.
There are hot keys to clear your screen too, such as ctrl+L (works in most shells) plus your terminal emulator will likely have its own hot keys too. So fewer button presses and even quicker for you.
Clearing just the screen without the scrollback history is pretty damn useless and in fact outright frustrating. It boggles my mind people read "clear the screen" and think "oh, surely he doesn't want to clear the scrollback buffer". You have to realize, a command for that is so close to useless it doesn't even exist as a separate operation on Windows. Over there, cls ("CLear Screen") does both and is incredibly handy. And on the incredibly rare occasions when I actively want to keep the scrollback buffer (read: like once every 2 months, tops?), I can already do that much more intuitively by scrolling down or holding Enter for 3 seconds. I don't need a separate command for it any more than I need a separate command to scroll down.
`reset` doesn't even clear the scrollback buffer on all terminal emulators. In fact there's no formal specification for how scrollback buffers should behave because they're a modern incantation. Take iTerm2, this is what happens when I run `reset` and then scroll up:
If you've already got a working solution then I don't see why this is problem. The way you've conversed in this thread sounds like it's a daily annoyance for you.
It was one for several years, until I solved it like this. It was such an unnecessary waste of my time. And it would not have taken nearly that long if everyone's response to "how to clear the terminal on Linux" on Google wasn't "clear" or "Ctrl+L".
Your idiosyncratic opinion what "clear" means doesn't make the answers wrong. "clear" clears the terminal. If you'd asked what you meant, ie. "how to clear the terminal screen and scroll buffer on Linux" you'd might have found ALT+CTRL+L which does what you want on most terminal emulators. Or you could have read the man page https://man7.org/linux/man-pages/man1/clear.1.html and found that the E3 property is what you want to know about.
I may be mistaken, but aren't you the one complaining that "clear" only clears the screen area and not the scroll buffer on libvte terminals? Or are you complaining that a different command on a different operating system does something different than a similar sounding command on another operating system with a command that sounds like it would only clear the screen but actually does clear the scroll buffer, too?
By the way, did you know that up to and including some versions of MS Windows 10 "clear" in Powershell only cleared the screen, as did "cls" in cmd.com. Considering the name, that would actually be what I expect "cls" to do, but I digress. Since some later MS Windows 10 versions or the very least, MS Windows 11, Powershell and cmd.com do clear the screen and the scroll buffer on "clear" or "cls". That's due to newer versions of ConPTY.
Anyway, it was fun digging out this old knowledge. Thank you.
Googles response is correct though. The scroll back is a “new” concept introduced by terminal emulators. It’s not something that ever existed in hardware terminals or even early pseudo-terminals (like the default console Linux drops you into if you don’t have a GUI installed). It’s just something that desktop software added.
Because of this, there isn’t really any standardisation for how scrollback should work. Every terminal could implement it differently (albeit in practice there isn’t a whole lot of variation one can do to such a simple concept). So support for how you clear your scrollback is going to vary from one terminal emulator to another. As I demonstrated in an earlier comment with ‘reset’ not clearing the scrollback on one terminal in macOS.
Really there should be a dedicated ANSI escape code for doing this. There’s a few different codes for clearing the terminal already, one extra wouldn’t do any harm there. Plus xterm has already introduced the concept of bespoke codes for application terms like window title (something other terms have expanded on with codes to move the terminal window).
In fact, I’m going to create a code for just this and implement it in my own terminal emulator and others are welcome to adopt this as a new de facto standard if they wish.
Anyway, that’s the history of why you had such a hard time. None of this is intended to justify the status quo, and I do accept that this is all a bit frustrating to newcomers. But as I said before, I don’t agree the solution is to change the purpose of ‘reset’. Instead terminal emulators should be supporting new functionality to manage something that they added to the paradigm — and to be fair, most terminal emulators already do.
> It’s not something that ever existed in hardware terminals or even early pseudo-terminals (like the default console Linux drops you into if you don’t have a GUI installed).
FWIW, the default Linux console had scrollback until a few years ago when it was removed in Linux 5.9.
Linus' comments on that commit are interesting to note too. Because, in my opinion, they add weight to the comments made on here regarding the annoying non-standardised complexities to terminal scrollback.
I literally edited my comment just before you said this because I suddenly realized someone was going to say this. No, the point is never just the "screen". The point is the whole buffer including the screen. Clearing just the screen is pretty useless to me, I might as well just scroll down or hold Enter for 3 seconds.
My terminal emulator of choice, WezTerm, has this feature built in [1], so there's no need for using `reset`. Perhaps your terminal emulator has something like it, too?
You could try echo -ne '\ec' or echo -ne '\033c'. Or this from bash/readline:
clear-display (M-C-l)
Clear the screen and, if possible, the terminal's scrollback buffer, then redraw the current line, leaving the current line at the top of the screen.
> Clearing just the screen is pretty useless to me, I might as well just scroll down or hold Enter for 3 seconds.
I actually do that a lot, when I'm done with a terminal window for now but want the scrollback to stay there. ctrl-L to send a pagebreak is what I usually do, or typing something aliased to `clear`.
