A mystery in the text editor

Hello, Linux terminal users! Let me present you a simple feature you’ve all seen, but might not have noticed.

You’re on the terminal, and you open a text editor of chice–nano, vim, emacs, acme etc.

After you edit for a bit, you close the editor.

Now you’re back where you left off. My question is, how? How does nano remember what used to be on screen? How does it get restored? Is nano doing this, or bash?

Well, I took at look at the source code to nano. Then I thought, “whoa! that’s way too complicated.” So I found a much simpler project called ted someone made to educate themselves. That was also a little complicated, but both seemed to use ncurses. So I wrote the following simple program, which also displays something and then restores the screen. Even though it’s very simple, it still works.

// Compile with: gcc -lncurses editor.c -o editor

#include <curses.h>
#include <stdio.h>

int main(int argc, char **argv) {
    initscr();

    refresh();
    printw("Hello world");
    getch();

    endwin();
    return 0;
}

Aha, so it’s something in ncurses, maybe. Let’s dive deeper.

So initscr() presumably saves the state in some fashion. endwin() definitely restores it, because if we comment that out, the terminal stops being restored. Since initscr() probably does lots of other irrelevant logic, we could take a look at endwin() to dive in. But let’s do something even simpler first.

As background, the linux command line is pretending to be an obsolete piece of hardware called a terminal. Specifically, it’s pretending to be a model called the DEC VT100 (or a later one, but they’re mostly backwards compatible). The terminal accepted text over a wire, and printed it to the screen.

When it got special text, it would do special things. These are captured today as “escape codes”–special non-printable characters, which cause your software terminal to also do special things. What kind of special things? Well one example escape code is “Backspace”, which deletes the last character. Another code is “\r\n” (carriage return; new line), which goes to the beginning of the line, and down one.

I suspect the answer to what’s happening with save and restore of my terminal might be some magic escape codes. So let’s just redirect the output to a file, and see what data is being center over the virtual wire to our virtual terminal.

$ ./editor >magic.txt
$ xxd < magic.txt
00000000: 1b28 421b 2930 1b5b 3f31 3034 3968 1b5b  .(B.)0.[?1049h.[
00000010: 313b 3530 721b 5b6d 0f1b 5b34 6c1b 5b48  1;50r.[m..[4l.[H
00000020: 1b5b 4a48 656c 6c6f 2077 6f72 6c64 6a1b  .[JHello worldj.
00000030: 5b35 303b 3148 1b5b 3f31 3034 396c 0d1b  [50;1H.[?1049l..
00000040: 5b3f 316c 1b3e                           [?1l.>

Well, that’s certainly a bunch of magic. Now something cool happens:

$ cat magic.txt

This command does nothing visible. It doesn’t print “Hello world”, even though that’s in the file. In other words, it’s printing Hello world, then really quick resetting the terminal. Just too fast for my poor human eyes to see.

We’ve confirmed the escape code theory! This file has everything we need. We can look at the source code to ncurses if we’re curious, but we don’t need to (and I won’t).

One thing I immediately see in this file, is that it doesn’t seem to contain the words that were on screen. So it’s not that the program read what was on screen, and printed it back later. Rather, there are some magic escape sequences happening to save and restore the terminal.

Okay, so somewhere in those 70 bytes is a magic code or two we want. Let’s examine all the bytes.

What kinds of escape codes appear here? Hex 0x1b is ESC, basically the escape sequence–it cues the terminal in that a special escape code is coming. 0x1b9b ( ESC followed by [) is the CSI escape code. DEC private codes refer to other escape sequences used by the DEC terminals like the VT00 (I’ll just shorten this to “DEC” below).

Without further ado, let’s break down those 70 bytes. Apologies for any errors below–correct me in the comments.

  • 0x1b (B
  • 0x1b )0
    • Set second character set to “DEC Special Character and Line Drawing Set” [xterm DEC guide]
  • 0x1b9b ?1049h
    • Save cursor as in DECSC and use Alternate Screen Buffer, clearing it first. [xterm CSI guide]
  • 0x1b9b 1;49r
    • DECSTBM: Set scrolling region to rows 1-49 [xterm CSI guide]
      (When I ran the program, my terminal was 49 lines tall inside tmux–so the whole terminal in other words.)
  • 0x1b9b m
    • (Empty) color and style set comand [ANSI/CSI]
      I think this could be left out entirely.
  • 0x0f (Ctrl-O)
    • Shift In. Use the standard character set. [xterm]
  • 0x1b9b 4l
    • RM: Replace Mode / IRM [xterm CSI guide]
      Typing doesn’t shift everything over, it writes over existing content.
  • 0x1b9b H
    • Move the cursor to “home” (top left of the screen) [ANSI/CSI]
  • 0x1b9b J
  • Hello worldj
    • The program prints “Hello world”. The final j was echoed when I pressed “j” to exit.
  • 0x1b9b 49;1H
    • Move the cursor to line 49, column 1 — the bottom-left corner [ANSI/CSI]
  • 0x1b9b ?1049l
    • Use Normal Screen Buffer and restore cursor as in DECRC [xterm CSI guide]
  • 0x0d (\r or Ctrl-M)
    • Carriage return [xterm]
      Moves cursor to column 0
  • 0x1b9b ?1l
    • DECCKM reset: Re-enables the cursor? [VT100]
  • 0x1b >

OK, solved. The magic save bytes are 1b 9b 3f 31 30 34 39 68 (<ESC> [?1049h). The magic restore bytes are 1b 9b 3f 31 30 34 39 6c (<ESC> [?1049l). And xterm or tmux is doing the save/restore magic, based on seeing this escape mode.

Hmm, how minimal can we get a working file, I wonder?

#!/bin/sh
echo -ne '\x1b[?1049h' # Save terminal
echo -ne '\x1b[H'      # Home the cursor
echo "Hello world"
sleep 1
echo -ne '\x1b[?1049l' # Restore terminal

Yep. That works fine.

ANSI: https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797
DEC: https://vt100.net/emu/ctrlseq_dec.html
DEC: https://vt100.net/docs/vt220-rm/chapter4.html#S4.6.18
xterm’s control sequences: https://www.xfree86.org/current/ctlseqs.html

Tagged ,

Installing Canon imageClass LBP-6000 on 64-bit Debian

(From Stack Overflow)

  1. 64 bit requirements for pre-made binaries:

    sudo dpkg --add-architecture i386
    sudo apt-get update
    sudo apt-get install libstdc++6:i386 libxml2:i386 zlib1g:i386 libpopt0:i386
    
  2. Install CUPS

    sudo apt-get update
    sudo apt-get install cups
    
  3. Download DriverGo to http://support-au.canon.com.au/contents/AU/EN/0100459602.html and download driver

    64e2d00f0c8764d4032687d29e88f06727d88825 Linux_CAPT_PrinterDriver_V270_uk_EN.tar.gz
    
  4. Extract and enter extracted folder

    tar xf Linux_CAPT_PrinterDriver_V270_uk_EN.tar.gz
    cd Linux_CAPT_PrinterDriver_V270_uk_EN
    
  5. Install the custom drivers and ccpd

    sudo dpkg -i 64-bit_Driver/Debian/*.deb
    
  6. Add the printer to CUPS and ccpd

    sudo lpadmin -p CANON_LBP6000 -m CNCUPSLBP6018CAPTS.ppd -v ccp://localhost:59687
    sudo lpadmin -p CANON_LBP6000 -E
    
    sudo ccpdadmin -p CANON_LBP6000 -o /dev/usb/lp0
    
  7. Set the default printer

    sudo lpoptions -d CANON_LBP6000
    
  8. Set ccpd to start on boot

    sudo update-rc.d ccpd defaults
    
Tagged , , ,

Screen and Tmux IDEs

I don’t usually like IDEs. They’re hard to switch off of, they do too much. They don’t let me customize things, and I always have to use external tools anyway. I’d really rather do things with a bunch of small tools, the linux way. The problem is, if I close everything, I’ll have trouble getting started back up again. Saving state is one solution. Quick start-up is another. Basically, write a checklist for myself to make starting things up easy (open such-and-such files in the editor, start the server in debug mode, etc).

But we’re programmers, so obviously we’re not going to use a literal checklist. Instead, we’re going to write a little script to auto-start things in a new screen session:

#!/usr/bin/screen -c
# game_development.screen.conf
# Run stand-alone or with screen -c game_devel.screen.conf
screen -t "Vim" 2 bash -c "vim -p *.t"
bind "r" screen -t "Game" 2 bash run.sh

Or if you prefer tmux:

# game_development.tmux.conf
# Run with tmux -f game_development.tmux.conf attach
new-session -s game_development
new-window -n "Vim" "bash -c 'vim -p *.t'"
bind r new-window -n "Game" "bash run.sh"

Note the main features being used: a shebang line hack for screen, to let this file be self-contained and executable. Opening files in vim in place of a text editor. Binding keys for unit tests, running the program, restarting the server, etc. Now, a similar approach is to add new key bindings to the text editor, but I feel like text editors should edit text, and I like being able to document all the additions with help menus (which screen and tmux both support).

Note: ratpoison is similar to screen/tmux so you can do similar things in X.

One thing I’d love is if this kind of file was easy to dump from the current state, especially for things like positioning windows, etc. A little assistance is available, but not too much. Ratpoison and tmux let you dump sizing information. Nothing outputs keybindings or a list of running programs with their windows.

There is a program called tmuxinator to let you write the same config in nested YAML of sessions, panes, and windows, which might appeal to some users.

Also, check out dtach if you don’t need panes and windows, and just want a detachable process.

Tagged , , , , , ,