Warum enthält der Befehl "reset" eine Verzögerung?

Der resetBefehl enthält eine Verzögerung zwischen dem Löschen des Bildschirms und der Rückkehr. Dies gilt sogar für den neuesten Terminaltyp xterm-256color. Warum?

man resetErwähnt keine Verzögerung, nur das Drucken von Sonderzeichenfolgen. (Es wird auch nicht erwähnt, dass der Bildschirm gelöscht wird. Ich gehe davon aus, dass dies in der Terminalinitialisierungszeichenfolge enthalten ist.)

Ich bemerke die folgende Ausgabe in strace -f reset:

nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffe1964f100) = 0
ioctl(2, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0

Echte (Hardware-) Terminals brauchen das. Beispielsweise besteht bei einigen die einzige Möglichkeit, sie zurückzusetzen, in einem Hardware-Reset.

Mit einem Terminal-Emulator ist dies harmlos. Da es keinen herkömmlichen Weg gibt, den Unterschied zu erkennen (und zu schwer zu bestimmen, ob eine Escape-Sequenz einen Hardware-Reset durchführen könnte), wird resetdavon ausgegangen, dass Ihr Terminal echt ist.

Die Zeitverzögerung geht auf tset3BSD im Jahr 1979 zurück:

    /* output startup string */
    if (!RepOnly && !NoInit)
    {
            bufp = buf;
            if (tgetstr("is", &bufp) != 0)
                    prs(buf);
            bufp = buf;
            if (tgetstr("if", &bufp) != 0)
                    cat(buf);
            sleep(1);       /* let terminal settle down */
    }

Es hat sich in ncurses etwas weiterentwickelt, verwendet aber die gleiche Richtlinie:

        if (!noinit) {
            if (send_init_strings(my_fd, &oldmode)) {
                (void) putc('\r', stderr);
                (void) fflush(stderr);
                (void) napms(1000);         /* Settle the terminal. */
            }
        }

Weitere Lektüre:

• Verlauf (tsetHandbuchseite)
• Verlauf (tputHandbuchseite)