| Summary: | konsole clears all the screen when I execute clear command even if the scrollbar is infinite. | ||
|---|---|---|---|
| Product: | [Applications] konsole | Reporter: | julien <lebreton.j> |
| Component: | bookmark | Assignee: | Konsole Developer <konsole-devel> |
| Status: | CONFIRMED --- | ||
| Severity: | major | CC: | a.samirh78, justin.zobel, kubry, lebreton.j, matt |
| Priority: | NOR | ||
| Version: | 16.04.3 | ||
| Target Milestone: | --- | ||
| Platform: | Kubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | attachment-23304-0.html | ||
|
Description
julien
2016-08-30 12:44:54 UTC
The escape sequence '\e[3J' is intended to (and indeed does) clear the entire scrollback. The "clear" command issues this sequence (among others). So I see two questions: - Why does such an escape sequence exist at all? Is it good to have it, is it good that konsole supports this? Wouldn't it be better if no escape sequence was allowed to wipe out the scrollback? Should konsole (and perhaps other terminal emulators) deliberately refuse to implement this? - Why does the "clear" command emit this sequence? As for the first, this is an interesting design question. As for the second, you're free to change your terminfo database, or come up with an alternate implementation of "clear" (maybe as simple as a shell alias) that does not wipe out the scrollback. See also: https://gitlab.com/gnachman/iterm2/issues/5058 https://bugzilla.gnome.org/show_bug.cgi?id=771953 *** Bug 382481 has been marked as a duplicate of this bug. *** In the end, iTerm2 introduced a dialogue prompt and an option to permanently inhibit for this escape sequence to clear all your scrollback. What about Konsole? Still unconditionally deletes everything, it seems. That's how the `clear` command works in konsole and xterm (and gnome-terminal); to get the behaviour you describe try 'clear -x'. > That's how the `clear` command works in konsole and xterm (and gnome-terminal); to get the behaviour you describe try 'clear -x'.
We are talking about conceptual denial of such potentially unwanted destructive action on a terminal emulator software level, not individual commands with some shady flags which no one knows about.
See other discussion threads linked above for more info.
AFAICS, this bug report is about the effect of using the `clear` command; please open a new report for any other issue(s). Sorry, Ahmad, but now I'm not sure you understood the topic right. What was the problem? The `clear` command erases all the screen including infinite scrollback. What was is that command `clear` uses to do it? It sends some special well defined escape sequence which is handled by the terminal emulator software, Konsole. What is the proposed solution? To provide an option to stop Konsole from handling this all-clearing escape sequence. It is THAT simple. Created attachment 132098 [details] attachment-23304-0.html Ratijas, as you said, it is that simple. Please look at the file VT102Emulation.cpp and provide a patch with the option for people that don’t want the clear command to clear the screen. On Sat, 3 Oct 2020 at 18:56 ratijas <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=368005 > > --- Comment #8 from ratijas <gmail@ratijas.tk> --- > Sorry, Ahmad, but now I'm not sure you understood the topic right. > > What was the problem? The `clear` command erases all the screen including > infinite scrollback. > > What was is that command `clear` uses to do it? It sends some special well > defined escape sequence which is handled by the terminal emulator software, > Konsole. > > What is the proposed solution? To provide an option to stop Konsole from > handling this all-clearing escape sequence. > > It is THAT simple. > > -- > You are receiving this mail because: > You are the assignee for the bug. I logged a bug like this at some point. My question is, how did this even happen? It used to work in a sane way, only clearing the current window's screenspace. I read the other issues and it's hard to say but some low-level physical terminal change caused this to happen in konsole? The new behaviour is insane. And it used to be fine for many generations of KDE.. To be honest, I've long since adapted and started using CTRL-L to clear just the current window's screenspace, but really I had such a huge habit of typing `clear` it was atrocious to switch. FTR, CSI 0-3J escape sequences behave in konsole similar to what they do in xterm, which is different than what the clear command does. And as I said before, clear works the same in both terminals. (In reply to Matthew from comment #10) > I logged a bug like this at some point. > > My question is, how did this even happen? It used to work in a sane way, > only clearing the current window's screenspace. > > I read the other issues and it's hard to say but some low-level physical > terminal change caused this to happen in konsole? > > The new behaviour is insane. > > And it used to be fine for many generations of KDE.. > > To be honest, I've long since adapted and started using CTRL-L to clear just > the current window's screenspace, but really I had such a huge habit of > typing `clear` it was atrocious to switch. It's no fix but alias clear='clear -x' |