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`.
Have you ever done anything constructive and positive in your life, or do you just fart around trying to get cheap thrills and boost your ego by trying to make fun of others?
Check out "The Man in The Arena" and get enlightened.
[
Citizenship in a Republic is the title of a speech given by Theodore Roosevelt, former President of the United States, at the Sorbonne in Paris, France, on April 23, 1910.[1]
One notable passage from the speech is referred to as "The Man in the Arena":[2][3]
It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.
Someone who is heavily involved in a situation that requires courage, skill, or tenacity, as opposed to someone sitting on the sidelines and watching, is often referred to as "the man in the arena".
I ran into one about 10 years ago. It was a bespoke diagnostic tool for some industrial machinery. It was only needed for last resort situations to get in via serial and gracefully rescue the HMI from a freeze or sync issue where the machine found itself in an impossible state doing maintenance to prevent having to do a physical lockout and shutdown situation or something like that. Never saw it actually used though as the beast was built before laptops and USB serial adapters were a thing. It was probably collecting dust for a decade before I came across it.
Probably the same people who use text editors which mangle "tab" characters. (never seen one ever, in 15-20 years of using computers and working with embedded devices)
One of my friends had a real VT-102 that he used on dialup bulletin boards for years.
Edit: also with our University VAX. Yeah, this was a while ago.
He had an RS-232 modem cabled to it, and would dial using AT commands.
I was thinking that Bloomberg still used dedicated terminals, but I just checked and nowadays they're just normal computers with dedicated software and custom keyboards.
I used to have some real (hardware) terminals, back in the day when (what we then called) IP Masquerading was still kind of new, Ethernet was still expensive to sensibly implement, and old cheap still-useful PC hardware didn't usually exist (and things like freebie "closet laptops" absolutely did not exist at all).
It was a bit of a different world back then. Most of my Internet and general-computing experience happened in a terminal -- whether xterm, 80x25, or a silly high-res BIOS-based text mode set using svgatextmode. Text-based web browsing with Lynx was still useful, and Pine (email) and tin (usenet) were well-suited to those applications at that time.
I had a desktop Linux (or sometimes, FreeBSD) box that I of course did all kinds of stuff with, and at least one remote shell account on a far-away computer to provide continuity, and I also had a couple of DEC VT330 terminals that I scored cheap at the Dayton hamfest. One was next to my favorite armchair so I could chat on IRC and listen to the stereo in the sweet spot at the same time. Another was in the bedroom, which I mostly used for reading books and other passive consumption.
It all worked well, of course. There was no reason for it not to work well. And at a time when the Internet was kind of a weird thing to be involved with at all, and almost always involved exactly one person using one dialup connection in exactly one physical location, I could meander around and do my usual Internet things in a few different locations in the house (thanks, screen!).
I didn't really build it for multiple users. But sometimes, the girlfriend would hang out and chat on IRC in one place while I did my own Internet things elsewhere, all on a light-weight 32-bit computer with only a few megabytes of RAM. It did fine.
---
But your question was present-tense. Because life has a way of things, I've sadly lost track of those VT330s. And your implication is correct: I haven't seen a standalone terminal in the wild for a really, really long time.
In the present-tense, I kind of miss the expediency of the interface. Many of us here use terminal emulators every day, so it may sound like I'm preaching to the choir, but I mean: The expedience of the text-based interfaces out in the wild. It is seemingly as lost as my VT330s are.
It used to be that if I needed a set of spark plugs for a car, then I might pop over to Autozone. The guy behind the counter there would mash in the make/model/year almost instantly on the terminal's keyboard, as if by muscle memory, and almost immediately he'd be rattling off different options, prices, and features.
Nowadays it's all web based. The parts store clerk's stupid-fast muscle memory has been replaced by mousing around interactively -- clicking and drooling (and worse: scrolling through stupid HTML dropdowns to find "Toyota," or "Volvo") through a website that is very much like the same website I can use from home. And that website sucks, time-wise, compared to the dumb terminal interface that they used to have muxed back to the home base.
(The only advantage I can find to the web interface that has been in place for a quarter of a century now is that it has pictures, but the pictures are often simply wrong. Bad data is no data, so this is a misfeature.)
A wonderful story and very interesting to think that things were faster in some ways when the laymen had to use the CLI/TUI.
Here I am in 2024 actually trying to rebuild a setup very similar to yours; I do a lot of regular text editing to take notes and logs and journals, and with the world moving the text-first notetaking tools like Obsidian (markdown) or the classic and lovely Emacs (org-mode/roam), it's become more and more important to write and access text quickly.
And I think even us on HN have seen similar push for text use as paramount: people scraping away the guff from websites to end up with summarized texts and pseudo-RSS feeds, NLP and LLM reworking text to make it evermore accessible to us humans.
Text is king. And the rest is just clutter.
So, given that, why not have more terminals around the home? Buying extra PCs and thin-clients is a start, but expensive - what I /really/ need is /interfaces/, monitors and keyboards to work /quickly/. In the age of smartphone soft-keyboards I think we can all agree that typing on them or doing text work is horrible. Yet that's where most text is written.
So my point is, maybe we shouldn't have strayed so far - and I think there's a vibrant community of hackers bringing back CLI/TUI as a primary method of interaction. In fact, the physical terminal TTY is actually still quite useful and common for embedded hardware engineers who use it frequently, or old school hardware enthusiasts like this guy [1] who use modern MCUs to work with the traditional terminal standards, which, of course, still work great in Linux like nothing has changed :)
To workaround it add the following to your shell's rc file:
function reset { printf '\e]\e\\\ec' }
Uses the VT100 RIS escape code to ask the terminal to reset itself. But first it send an empty OSC escape to reset the terminals VT parser back to normal mode, so that the RIS escape code is parsed correctly. No need to depend on any external utilities like tput or the reset binary. This should work with any halfway decent terminal emulator.
>and since there's no conventional way to tell the difference (and too hard to determine if some escape sequence might do a hardware-reset), reset assumes your terminal is real.
Sure, okay, but there's two problems with that:
1) you have to trust the user to get that right, and
2) how do you know it's an actual hardware terminal and not a terminal emulator?
> TERM is already used for determining color support.
It's one of many ways to determine colour support. And arguably the worst of all of the ways too.
- $TERM
This isn't intended to contain colour information, yet that's how it's often abused. Meaning a lot of applications are broken in non-xterm terminals if they happen to use the $TERM variable correctly
This is the correct way to check for a device capability. But it requires more effort and knowledge of terminals than your average developer has. So is rarely supported by console applications.
- $COLORTERM
This is the modern day equivalent to the device capability API. But also isn't used often
- $COLORFGBG
This was the original env var intended to be used like $COLORTERM, but fell out of favour because, well, nobody bothered to read any docs.
- $FORCE_COLOR
This is an often used standard. Christ only knows why this one exists when we already have 3 other env vars being used this way. Another example of nobody bothering to read any docs
- $NO_COLOR
This is intended to do the opposite of the others and tell applications not to use colour. However even this is often ignored.
----
That's 6 different ways to check whether to colour output or not. Only one actual standard method and everything is only partially supported (if at all) in applications. Hence why applications then need a `--color` flag, which even that differs in support and syntax across different command line tools. And the "default" method you described, $TERM, actually breaks applications on alternative terminal emulators and hardware terminals -- that is unless they decide to announce themselves as `xterm` and in that case that environmental variable becomes entirely pointless because it has naff all to do with terminal listening.
----
> Not sure what terminals do without color support with color escape codes.
They ignore them.
ANSI escape codes are a pain in the arse to parse but there is at least a documented standard way to parse them. Anything that is a CSI (Control Sequence Introducer) sequence, and that includes SGR (Select Graphic Rendition) parameters like colour codes, start with `{ESC}[` and terminate with a character in the range of 0x40 to 0x7E. It's actually a little more complicated than that[1] but that's the gist of it.
So you know what to print and what to ignore.
There are other escape sequences too, the other big one being OSC (Operating System Command) and they're terminated `{ESC}\`, which is usually referred to as ST (String Terminator). That is unless you're xterm, and then you terminate OSC sequences with either ST or BELL (char 0x07).
A lot of this makes more sense if you look at code rather than documentation. So I've made an effort to ensure my own terminal emulator's source code is as self-documenting as possible, eg[2]
1. It’s just an env var and users frequently do fiddle with it
2. That’s great in theory, but in practice a lot of software is written expecting TERM to contain, for example, xterm.
The TERM env var is actually worse than HTTP User-Agent for fingerprinting. And for all the same reasons why User-Agent is a hot ball of mess.
The way capabilities between different hardware terminals are usually detected is via special interactive ANSI escape codes. But there isn’t currently one to ask if the terminal is hardware or software.
So you're advocating inflicting an annoying delay on tens of thousands of people because there might exist one person a) uses ancient hardware and b) uses recent software and c) messes with their TERM environment variable?
> Yes obviously it can be worked around by tens of thousands of people. We weren't discussing that. This is about the default which is clearly an insane default in 2024.
But what you're advocating isn't changing the default, it's changing the purpose of reset.
If people want something to clear the scrollback buffer then a new standard, and thus tool too, should be implemented. And in fact there are other ways to clear the scrollback buffer. You're just insistent on complaining that one very specific tool which is intended for a whole other purpose also clears the scrollback buffer slightly quicker...
> Rubbish. There are obviously other options:
> * Don't upgrade their software (almost certainly the case already).
That might not be an option. Some financial systems still use older style null terminals in places.
> * Install a version of `reset` that has the delay.
Given you're strongly against having to install a version of `reset` that doesn't have the delay, you're hardly in a position to demand other people to install a version that does.
> * Add an option to `reset` to add the delay.
That's not really practical on most systems because `reset` is just a symlink to `tset`
> * Stop using a physical terminal.
That's about as unhelpful a suggestion as it comes.
> If you're ever wondering why it will never be the year of Linux on the desktop, it's because of attitudes like yours.
Please don't make personal attacks. Plus waiting a couple of seconds for a command line terminal to clear when using one specific command has absolutely naff all to do with "the year of desktop Linux".
If you bothered to do even the smallest amount of research on me, you'd realise that I'm massively in favour of modernising the command line. I've written a next generation shell that, frankly, leaves most others in the dust. And I'm not working on a terminal emulator that can in-line multimedia and other interactive GUI components. The problem here isn't my attitude, it's that the arguments in favour of changing `reset` are bullshit nonsense that both misunderstand the purpose of `reset` and also risk breaking a whole plethora of hardware because of that misunderstanding of yours.
>That might not be an option. Some financial systems still use older style null terminals in places.
But how many of those setups require a custom TERM and are unable to install a different package for reset.
>Given you're strongly against having to install a version of `reset` that doesn't have the delay, you're hardly in a position to demand other people to install a version that does.
The amount of people who need that delay is miniscule compared to the people who don't. Normal users don't need the delay, only exotic setups, which is why the default does not make sense.
>That's not really practical on most systems because `reset` is just a symlink to `tset`
Then stop doing that.
>That's about as unhelpful a suggestion as it comes.
Not really. It has practical benefits and avoids down time of having to get it repaired or replaced.
>Plus waiting a couple of seconds for a command line terminal to clear when using one specific command has absolutely naff all to do with "the year of desktop Linux".
His comment was about your attitude of tailoring the system to a niche group instead of tailoring it to the billions of potential desktop users out there.
Let me be clear, I’m not against support your requirements. I’m saying ‘reset’ is the wrong tool to do that.
It’s like complaining that a text editor has no support exporting files as a PNG just because a subset of people happen to use that text editor for ASCII art.
If you want better support for clearing scrollback then that problem lies with ‘clear’, not ‘reset’.
Just as terminal capabilities lie with ANSI escape codes, not the TERM string.
The issue here is the pair of you are asking for the wrong thing then ignoring literally everyone else on HN and proceeding to make up insanely stupid claims about affected users (“billions of desktop users” lol) and call everyone else out for being unsupportive. Perhaps if you bothered to listen to people you might actually learn something.
Windows has also maintained backwards compatibility to a ridiculous extent, and there have been a bunch of "year of the Windows desktop", so I don't think it is detrimental that Linux does the same.
The issue is not about maintaining reasonable backwards compatibility. It's about refusing to fix things and using ridiculous backwards compatibility as an excuse.
1. Even Windows doesn't maintain full backwards compatibility all the way to the 90s, which is what you are advocating.
2. You could even fix this in a backwards compatible way if you wanted!
Also I never said anything about "full backwards compatibility". I just think this specific compatibility is worth preserving because your justifications are weak (by your own admission, you're only arguing about it because you enjoy arguing with people on the internet).
> 2. You could even fix this in a backwards compatible way if you wanted!
It has been. You objected to those backwards compatible fixes.
I've also suggested a way of patching `reset` without relying on buggy usages of `$TERM`. That also apparently isn't good enough for you.
> you're only arguing about it because you enjoy arguing with people on the internet
Not at all. Firstly I clearly stated a second reason so that isn't the only reason. And secondly, that's orthogonal to whether or not I'm right. If I didn't enjoy debating I wouldn't bother but I would still know that maintaining this delay is idiotic.
> It has been. You objected to those backwards compatible fixes.
It has not. If I install a default Linux distro, the default configuration is to insert stupid delays everywhere.
I have to go out of my way to remove them. That. Is. Dumb.
You can change it though. Several people in this conversation have suggested ways to make that change.
What you're asking is different. You want to make a global change to a core application in ways that are incompatible with existing, albeit extremely old, hardware. And the only justification is to speed up a non-standard use case for said tool. And you're pushing for this despite there already being purpose designed solutions to your exact problem.
Linux (and GNU in general) frequently makes breaking changes. Like dropping 386 support. But it's done where there are actual real world problems. Like maintainability. Or security (why certain features were dropped from GNU Bash ~10 years ago).
I get this delay is annoying for you but it's literally just a 1 (one!!) second sleep:
(void) napms(1000);
If 1000 milliseconds is that valuable to your productivity then why are you wasting millions of them arguing with strangers on the internet?
If feels to me like there a real lack of objectivity in this thread.
> If 1000 milliseconds is that valuable to your productivity then why the hell are you waste millions of them arguing with strangers on the internet?
Yes it is that valuable to me, because it isn't a single 1s delay. I endure it many times per day (or I would if I didn't fix it for me). And of course you know that little delays cost more than their "raw time" because they interrupt flow.
And I'm arguing with people on the internet about it because 1. It's fun to argue with people who are obviously wrong, and 2. I care about other people and I would like them to not have to endure this idiotic paper cut.
If I'm obviously wrong then I assume you can point me to an independent study that proves a 1 second delay in `reset` has measurable significant impact on peoples productivity?
> If I'm obviously wrong then I assume you can point me to an independent study that proves a 1 second delay in `reset` has measurable significant impact on peoples productivity?
That's the wrong question. Nobody has done that study because it's obviously bad to have 1 second delays that aren't needed!
Show me an independent study that proves a 1 second delay has no negative impact on productivity or satisfaction.
Very often unfortunately. But even when it doesn't I use `reset` to clear the scrollback history so it's easier to get to the start of a command.
I'd really like terminal emulators to support marking the default top of the scrollback so I don't lose the earlier history but still get the benefit of being able to easily find the start of a command, but I'm not aware of any terminal emulators having any features that do anything like that. So `reset` is the next best thing.
Lots of terminal emulators support graphical hints to box command output together. There was even a discussion about this exact feature just a few days ago on HN.
You can also emulate this behaviour in your shell using the prompt string. Which is something I see a lot of people do too.
You probably can’t do either of these things in the VSCode term that you like, but that term is shit.
> If a user misconfigures what their current terminal is there isn't much that can be done.
We aren't talking about people misconfiguring their terminal. We are talking about application developers abusing the $TERM command to detect terminal functionality rather than using ANSI escape sequences to detect a terminals support. And thus people then need to spoof $TERM strings to retain the same functionality.
This is why you often see $KITTY, $MXTERM and other env vars in addition to $TERM.
source: I wrote my own terminal emulator. $TERM these days is garbage.
> It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed.
New terminal emulators do. Plus we already have ANSI escape sequences for detecting terminal functionality and it was purposely designed for hardware terminals in mind. Just doing the kids school run but I can share a link to them when i return
From my experience, the list of new terminals IS always growing.
Wayland? A developer wanting to flex their Rust or Go muscles? Poor Unicode or RTL support? Slow buffer? "I can GPU accelerate the terminal"? Tiling? Dropdown on tilde? Keypress customization? Better cross-platform compatibility? Sixel support? "We're a trendy yet ancient mega-corp that now supports open source please use our cloud product"? ... all reasons I've seen a new terminal or three.
Last night, I ssh'd into a server that had a huge TERM list but alacritty was not on it, so I had no dircolors even when using --color=always. The only reason I'm even using alacritty is due to my last terminal not working well on new hardware.
I don't have a better solution. Obviously the terminal should self-report its capabilities and everyone writes software respecting those, but that ship has sailed, so we're stuck with QWERTY as a keyboard layout (or whatever your country collectively uses; FR, DACH, etc), x86 as an architecture, and TERM as a variable.
You're missing a vital point here due to the overloaded nature of the word 'terminal'.
The number of HARDWARE terminal types is not growing rapidly - few people are putting out new serial terminals where the TERM variable is intricately tied to the functionality of the terminal (and in many cases, even hardware terminals can emulate a few well known terminal types).
The software you're talking about are terminal EMULATORS. They emulate the functionality of a hardware terminal, interpreting the escape sequences emitted by the software they're running in order to refresh a user display. You can have many, many new terminal emulators created without needing a new terminal list entry if they are emulating existing terminals.
So let someone create 100,000 new Wayland terminals - they're likely going to be emulating vt100 or some variant of xterm. They don't need their own terminal entries.
TERM is meant to apply to hardware and software (emulated) terminals. But in reality a lot of application software just looks for the string “xterm-256color” to decide if it’s a modern terminal or not.
The problem is that I’ve seen applications even drop basic VT100 features if a $TERM doesn’t contain ^xterm. Which is insane.
And all of this is using the wrong tools for detecting terminal capabilities because the old hardware terminals couldn’t define environmental variables for the host running the shell. In fact a lot of hosts didn’t even run UNIX, never mind have the concept of environmental variables.
So there are ANSI escape sequences that request the terminal to reply (with a similar escape sequence) what that terminals capabilities are. That’s how termcap and other responsible tools work, and thus how ‘reset’ would also need to work given it is a symlink to ‘tget’
Env vars are definitely convenient in the modern era of operating systems and terminal emulator so I do understand why people lean on them. But the problem is they’re not standardised. So you get different people using different vars (like $TERMCOLOR $TERMCRGB $NO_COLOR $TERM $KONSOLE $KITTY etc) all for overlapping concerns. It’s a fucking mess because developers either didn’t read the manual, or have to support other developers who didn’t read the manual.
So this is why I’m against using ‘reset’ using $TERM to detect device capabilities.
This is also why my own terminal emulator, despite not being related to xterm at all, identifies itself as xterm in $TERM. It sucks that I have to, but that’s just how it is.
The next question is whether ‘reset’ should even be the place for this code. I’d argue not because the requirement isn’t to reset the terminal, it’s to clear the scrollback. So the place for this change is ‘clear’, not ‘reset’.
> You keep track of a list of what TERM are hardware based that need this delay
How does this work for a terminal emulator? Say I'm using Kermit, and I'm using its VT100 emulation. My term would be VT100. So this delay would still be present because my terminal emulator is emulating the VT100, so looking at the TERM variable won't fix that.
