Why does the `reset` command include a delay? (2017)
unix.stackexchange.com
unix.stackexchange.com
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.
> making millions of people waste 3 seconds
> That's a touch exaggerative don't you think?
Literally!
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.
Sadly Kitty is very bare-bones. Not really for me. And I can't choose to use Kitty in VSCode.
I said most terminal emulators are cross platform and that hot key isn't an OS dependant thing. You then reply with:
> On Mac you can press Ctrl-K in any terminal emulator ... > On Linux no terminal emulators support this
which not only contradicts what I said, it also misunderstands how terminal emulators work
> and I can't choose to use Kitty in VSCode.
So the issue is VSCode doesn't support ctrl+k? that's very different to the statement you opened with
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.
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.
Ah yes, the logical shortcut for "find" (enormous face palm).
Why do so many open source devs find sane UX so hard? It's a bit weird.
(And yes I know it isn't exactly the same as "find" - it that is your instinctive response then you're misunderstanding how UX works.)
Gnome Terminal sensible uses Ctrl+Shift+F to get around this. Kitty... does not.
> 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.
Of course you think that.
And pretty much anyone that has to deal with internet commenters using the term UX thinks that, not just me.
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.
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.
reset() { clear && printf '\33c'; }[1] https://wezfurlong.org/wezterm/config/lua/keyassignment/Clea...
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`.
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?
Yes. See sibling replies.
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.
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.
lmorg ~ % reset
lmorg ~ % reset
lmorg ~ % which reset
/usr/bin/reset
lmorg ~ %
function reset {
printf '\033c'
}
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.
FWIW, the default Linux console had scrollback until a few years ago when it was removed in Linux 5.9.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
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 think that is the real problem here.
What? This is not my idiosyncratic opinion. This is literally what cls ("CLear Screen") does on Windows.
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.
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.
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.
stty sane Ctrl-J
See: man stty
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.
https://en.m.wikipedia.org/wiki/Citizenship_in_a_Republic
Relevant excerpt:
[ 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.
]
I wonder who uses real terminals and for what.
I'm guessing the same people who believed 1991 was the year of Linux on the desktop.
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.)
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 :)
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.
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.
The TERM environmental variable can be used
2) You keep track of a list of what TERM are hardware based that need this delay
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.
If a user misconfigures what their current terminal is there isn't much that can be done.
>but in practice a lot of software is written expecting TERM to contain, for example, xterm.
It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed.
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
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.
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.
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’.
Ridiculous
But for people who have physical terminals, which I know is exceedingly small, there is no other option. Hence why the behaviour still exists.
If time is your only constraint then use a clear screen hot key or write a function and make it a single char, like the following:
function r {
printf '\033c'
}
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 feels to me like there a real lack of objectivity in this thread.
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.
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.
But I can see nothing further is going to be gained from this conversation so I'll end it here
I have to run it, tops, maybe once a day when a remote screen session gets disconnected.
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.
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.
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.
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
- ANSI code: CSI 22 c (Send Device Attributes, ANSI color)
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] https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_...
[2] https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c1...