It is able to copy the framebuffer from the virtual consoles of F1 to F6 (and also any others when "activated" in that system, usually that means non-commented in /etc/inittab, e.g. F8-F12)
You can only see what is to be seen when switched away and back to the VT, meaning when you scroll up in that virtual console, that what is there cannot be captured, since the VT switches back to the very last part when you switch to another virtual console to run "ct", or back to X to run "ct" it from an xterm.
About the other way round... monitoring an xterm, sadly, I was never able to figure how to copy from an xterm... It's only working for monitoring virtual consoles, so the program you want to capture, debug, monitor or create documentation for needs to run on one of the virtual consoles...
Please be aware that you need to be root, only root has the privilege to read the needed /dev file. Without reading that /dev file, no capture is possible.
# ct (meaning *c*at*t*erm or *c*apture *t*erminal) (c) Rava
# usage: ct 1 for cat of tty1 from other console or xterm.
# ct 1 1 for cat of tty and tail only 1 (=last) line, good for ctorrent or wget output or such.
# Cave! $COLUMNS needs to be exported prior running ct!
if [ "$COLUMNS"x = "x" ] ;then
echo $MYNAME V$VERSION - could not read \$COLUMNS - assuming 80.
if [ $# -eq 1 ]; then
cat /dev/vcs$1 | fold -w $COLUMNS | sed 's/[ \t]*$//'
elif [ $# -eq 2 ]; then
cat /dev/vcs$1 | fold -w $COLUMNS | sed 's/[ \t]*$//' | tail -n $2
echo $MYNAME V$VERSION Unknown parameter - Abort.
It only works okay when the $COLUMNS of the virtual console or the xterm you might start it from have the same columns / width, e.g. 80 for both. Otherwise the needed folding will mess up the lines!
Usually the variable $COLUMNS is not exported and so cannot be read by the xterm or virtual console script. (It can be read when you type the one-liner in the terminal by hand, but not in a script, that is. Dunno why that is so... mc can read the size of a terminal, so can all other terminal programs, but my script needs the $COLUMNS to be exported... Me thinks that's because it is "just" a script. )
Therefore you need to put export COLUMNS into /etc/profile when you want to capture from the VT, or into It only works okay when the $COLUMNS of the virtual console and the xterm you might start it from have the same columns / width, e.g. 80 for both. Otherwise the needed folding will mess up the lines!
Usually the variable $COLUMNS is not exported and so cannot be read by the xterm or virtual console script. (It can be read when you type the line in the terminal by hand, but not in a script, that is)
Therefore you need to put the line "export COLUMNS" into /etc/profile when you run the script from a virtual console. When you want to run it from an xterm, you also need to put the line into ~/.bashrc from the user who starts X, by default that's "guest".
Or run that line "export COLUMNS" beforehand on the VT or XTerm you want to run the script from.
The script can be especially handy since you can use it in other scripts, like, make a screenshot every 10 seconds and append it into a certain file for monitoring software, or for debugging.
Or when you start compiling a complex software or the kernel in a virtual console, you no longer need to switch to that VT via e.g. Ctrl+Alt+F1, just type "ct 1"
Cave! Some Linux use /dev/tty* while others use /dev/vcs* !
Usually, both refer to the Virtual Consoles, but I never encountered a system that would use both, it is either tty or vcs! So, if you want that script on another Linux and it fails, just try to change the part of the lines from /dev/vcs* into /dev/tty*.
Could be that there are even more possible variants, but these two are the ones I encountered. Newer Linux'es all seem to use /dev/vcs*, while oder ones use /dev/tty*.
Hope some of you think of my script as helpful and handy, I use it often. One can sure switch to the console and copy & pasta with the mouse, switch to another console to put it into the text editor and so on.
But just having "ct 1 5 >debug" running as often as you need it, e.g. every 5, 10 or 60 seconds is way more handy that the need to do the capture manually every time. And you can leave the machine running by itself and later on look into the captures if all looks okay, or create the captures for documentation, since you can use text/html and there is no need for a png/jpeg screenshot. In a way, a HOWTO can be created more easily and even quicker for a wiki or forum.
Known bug: No check if the one or the two given parameters are valid numbers, these errors would look like so:
root@porteus:/mnt# ct 1 n
tail: n: invalid number of lines
root@porteus:/mnt# ct n
cat: /dev/vcsn: No such file or directory
Not debugged, since I think the user gets enough info to realize how to run "ct", and it must be run as root, and anyone who runs a script as root should be able to figure out how to use ct. [Still, I should implement -h / --help]
What could be added is some help/info lines via the usually suspects "-h / --help" e.g. telling the user about the valid parameters and how to put the export COLUMNS into one or both files for being able to capture from virtual console or xterm, or both. [The stuff I already explained above]
Since I coded it mainly for myself, therefore knowing how to use it, so far I saw no reason to implement a help. But if many folks think it's a neat little script, I might be tempted to include such help. (Since having a script be appreciated makes the coder a happy camper. ) </lazy 'n busy Rava>