When I use clear command to clear the screen. It is not cleared (see screenshot when I scroll up a bit after command done)

enter image description here

So I double the command to get right behavior:

$ clear && clear && DD=0 ...

enter image description here

Why do I need to double the command to get cleared screen?


Actually if I just clear I got cleared screen. But I can scroll up and see last 25lines (if screen is 80x25). When I run clear;clear I got those lines cleared.

  • 4
    Try tput reset instead of clear Jul 6, 2017 at 13:32

2 Answers 2


The important thing to note here is the tag on the question. This behaviour is specific to GNOME Terminal and any other terminal emulators that are built upon libvte. You won't see this in Xterm, or in Unicode RXVT, or in the terminal emulator built into the Linux kernel, or on the FreeBSD console.

What happens in general is this.

  1. The clear command looks at terminfo/termcap and issues appropriate control sequences.
    1. If the terminfo/termcap entry has an E3 capability it, it first writes out that. This issues control sequences to clear the scrollback buffer. This and the history behind it are documented in detail in the Dickey ncurses manual page for the clear command.
    2. It then uses the clear capability to clear the visible screen.
  2. The control sequences in the terminfo/termcap entry are determined by the terminal type; but, with the exceptions of the (nowadays rare) terminals that use FormFeed to clear the screen (which DEC VTs and their imitators do not), they are either just plain old ECMA-48 control sequences or extensions thereto. For examples:
  3. The terminal emulator acts upon the control sequences. As defined by ECMA-48 and the Xterm extension to it:
    • CSI H (CUP) homes the cursor.
    • CSI 0 J (ED 0) or just CSI J erases from the current cursor position to the end of the screen.
    • CSI 2 J (ED 2) erases the whole screen.
    • CSI 3 J (ED 3) erases the scrollback buffer.

When it comes to GNOME Terminal in particular:

  1. The terminal type is properly gnome, but some people leave it erroneously set to xterm.
  2. The gnome terminfo entry does not define an E3 capability, and on many systems — still! — neither does the xterm entry as this has not percolated down from Dickey terminfo. So clear just writes out the contents of the clear capability.
  3. The contents of the clear capability for those terminfo entries are the control sequences to home the cursor followed by erase the whole screen.
  4. But GNOME Terminal does not implement erase the whole screen correctly. More specifically, the library that it is based upon, libvte, does not do that in the code of its VteTerminalPrivate::seq_clear_screen() function. Rather, libvte scrolls the screen down an entire screen's worth of blank lines, and moves the cursor position to the first of those blank lines.

This is why you see what you see. libvte is not erasing the whole screen when told to. Rather it is doing something that has a superficial resemblance to that, until one does exactly what the questioner has done here: scroll the terminal window back to look at the scroll back buffer. Then the difference is blatant.

On other terminal emulators such as Xterm and Unicode RXVT, the ED 2 control sequence really does erase the screen, erasing every position on the screen in place, from the top down, and not altering the scrollback buffer. But on libvte terminal emulators, it just pushes the current screen up into the scrollback buffer and adds a screen's worth of blank lines. The prior screen contents are not erased but shifted into the scrollback buffer.

And if you run the clear command twice, it adds two screen's worth of blank lines. If your scroll back buffer is large enough, you can still find the original screen contents, simply further up in the scrollback buffer.

Further reading

  • 3
    Maybe to do alias clear='clear && printf "\033[3J"' is a viable solution ?
    – user232326
    Jul 6, 2017 at 21:23
  • 1
    "The terminal type is properly gnome, but some people leave it erroneously set to xterm." – This is not true. gnome-terminal (VTE) has for many years defaulted to "xterm" and later "xterm-256color". This is the choice made by its developers, and used by them for testing/developing. Its emulation is reasonably close to xterm's in practice, and the gnome terminal description is abandoned. Sure piggybacking another terminal description has plenty of downsides, but so is maintaining a separate one, it's two far-less-than-ideal possibilities the project had to choose between.
    – egmont
    Dec 13, 2017 at 22:52
  • 3
    "But GNOME Terminal does not implement erase the whole screen correctly." – This is indeed one of the places where VTE differs from xterm, you even linked its tracking bug. Note that xterm's behavior has drawbacks too that VTE doesn't, e.g. pressing Ctrl+L in bash wipes out the last screenful of data in xterm, but not in gnome-terminal.
    – egmont
    Dec 13, 2017 at 22:54
  • 1
    The gnome-* and vte-* family of terminfo entries is most definitely not abandoned, and indeed was most recently updated as I write this in July 2017 and January 2018. And it most definitely is true that it is erroneous to use xterm for it. The GNOME developers are quite wrong here.
    – JdeBP
    May 30, 2018 at 12:46

If you want to clear the terminal and destroy the whole output buffer, I'd recommend doing tput reset. That will definitely clear the terminal and fix its state as a bonus if e.g. any previous program crashed and left the terminal in unclean state. In addition, the tput should be clever enough to figure the correct terminal type so you don't need to know if your terminal uses VT100 or some other command sequences.

As tput reset is defined by POSIX, it should work in any POSIX compatible system, too: https://pubs.opengroup.org/onlinepubs/007904975/utilities/tput.html

  • It is specifically specified by POSIX to reset the terminal "in an implementation-defined manner". For example, on my system, it does absolutely nothing (in particular, it does not clear the screen nor the scrollback buffer).
    – Kusalananda
    Feb 13 at 14:24
  • @Kusalananda Wow! I didn't expect any terminal to reset without clearing the screen. Which terminal emulator do you use? Feb 13 at 15:02
  • Konsole is the only terminal I use that doesn't clear the scrollback with tput reset. It seems that Konsole version 21.12.3 requires <ESC>c to clear the screen and <ESC>[3J to delete the scrollback buffer but that doesn't clear the screen. As a result, echo -ne '\e[3J\ec' should be able to clear the scrollback and the screen but this is not portable. Feb 13 at 15:20
  • 1
    iTerm on macOS, with an SSH session running tmux inside on an OpenBSD system. That tput reset command does clear the terminal in iTerm locally, but does not reset the scrollback buffer.
    – Kusalananda
    Feb 13 at 17:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .