I just spent the last two hours running a dd command (or picture any similar "difficult to re-do" scenario) from a live CD without a GUI; all I have is my trusty "multi-window" (CTRL+ALT+F#) Bash terminal.

Alas, during the command dd threw out several nasty error messages and a bit more information that I would like to keep. I have a USB drive plugged in to which I can write data, but how do I get the previous output saved as a text file after the command has already been run?

If this had been a terminal emulator inside a nice GUI, I would have simply used my mouse to select the text, copy it, and paste it into a document. And had I known the command would have produced errors, I would have piped it out to a file to begin with, but alas, the additional output came as a surprise.

How do I save text output from my previous command to a file without re-running the command? Is this even possible?

  • I have been searching for ways to select text on the screen, but so far I'm only finding ways of doing this using text you have entered into the prompt.
    – IQAndreas
    Commented Mar 16, 2015 at 23:19
  • Have you tried using output redirection??
    – eyoung100
    Commented Mar 16, 2015 at 23:26
  • 2
    @eyoung100 Is that another word for "piping"? As in dd if=/dev/sda of=/backups/sda.img > result.txt. If so, the problem is I already ran the dd command. At all costs, I want to avoid running the command again, which in some situations is impossible.
    – IQAndreas
    Commented Mar 16, 2015 at 23:29
  • 2
    Assuming this is Linux: install gpm. (Start it if necessary, e.g. service start gpm). Sweep out a region while holding down the left mouse button. Type cat > outputfile and click on the right mouse button to paste the region you just selected. Commented Mar 16, 2015 at 23:47
  • 1
    If the objective is solely "to keep ... [the] information", a last resort is to grab a camera and take a photograph of the screen. (And, theoretically, you could then run OCR on that.) Commented Mar 16, 2015 at 23:57

2 Answers 2


A linux kernel should store an on-screen log for your vts in the corresponding /dev/vcsa*[ttynum] device.

It is why the following works:

echo hey >/dev/tty2
dd bs=10 count=1 </dev/vcs2

...which prints...


The corresponding /dev/vcsa[ttynum] device will store an encoded version of the formatted text on-screen, whereas the /dev/vcs[ttynum] will be a plain dump. The vcsa[ttynum] devices will encode a pair of bytes which describe each on-screen char and its attributes, as well as a string at the head of each logical page that indicates the referenced tty's lines,columns count.

As @kasperd points out, I had it wrong before by assuming the \a BEL was encoded between every character, when in fact: The default color combination happens to coincide with the bell character.

For your purposes using the /dev/vcs[ttynum] is probably easiest. Here's a look at the differences:

echo hey >/dev/tty2
dd bs=10 count=1 </dev/vcs2 |
sed -n l


hey       $


echo hey >/dev/tty2
dd bs=10 count=1 </dev/vcsa2 |
sed -n l


  • 1
    vcsa doesn't put the same character between all characters. It give you pairs of bytes telling you which character is on the screen and which color it has. The default color combination happen to coincide with the bell character.
    – kasperd
    Commented Mar 17, 2015 at 8:45
  • @kasperd - thank you. Is it better?
    – mikeserv
    Commented Mar 17, 2015 at 8:51
  • That's better. 👍
    – kasperd
    Commented Mar 17, 2015 at 8:54

Go to (/log in on) another terminal and run sudo screendump N > screenoutput.txt, where N is the number of the terminal you want.

No backlog, I fear. If those virtual consoles keep one, I've never seen it. But it gets you all you can see on that terminal.

  • if it does work, it's probably because it grabs it from /dev/vcsa*[1-9]* - (which is what I would guess the superuser permissions are for). The linux consoles have supported a backlog for most of the 3.* series as well, I think. I'm not sure how one might grab it (opposed to using the /dev/vcsa*[1-9]* devices) but maybe there's a way.
    – mikeserv
    Commented Mar 16, 2015 at 23:34
  • It's better not to switch to a different console, as switching erases the backlog, retaining only what is currently visible on the screen. Commented Mar 16, 2015 at 23:44
  • @mikeserv Yes. Well, the man page seems to say it uses both /dev/vcs$i and /dev/vcsa$i. It gives a readable result though. ;-) Commented Mar 16, 2015 at 23:45
  • @Gilles Ah, so there is a backlog? But screendump doesn't get at it, even if I stay in the same console. Commented Mar 16, 2015 at 23:46
  • 1
    You can see the scrollback by typing Shift-PageUp one or more times. I don't know of a way to snarf the text in the scrollback other than using the mouse via gpm. Commented Mar 17, 2015 at 0:13

You must log in to answer this question.

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