|XP is just a number|
Re^2: how to strip VT100 escape sequences?by jakobi (Pilgrim)
|on Oct 22, 2009 at 12:04 UTC||Need Help??|
Then there's Guide de Rosa's unescape.pl, stripping both too little and probably too much.
I added some more stripping to better cope with ANSI/ curses esc sequences or vi sessions. Consider script's typescript of a shell session in which you invoked mc or vi. A bit less messy & more grep-able than before, but still by no means a clean session command + output protocol. See also my notes at the start of this script. I update my version each time when I run into too many esc sequences in a transcript. But it won't ever be able to do a 100% job.
Some more information and keywords can be found e.g. in http://invisible-island.net/xterm/ctlseqs/ctlseqs.html, in this case fromt the xterm side of things.
IIRC, weren't there length-determined arbitrary byte sequences as well (w/o end character)?
Basically either you know both $TERM and the real terminal interacted with in the session (incl. it's initial settings and size), and reimplement all escapes for both of them (at their specific versions at that point in time even?), or you'll never be able to catch exactly 100% of the sequences being generated or intercepted by terminal or application. Finally add some line-noise for flavour, a pinch of bit-rot, exactly 7 bits of a multi byte encoding, stir & enjoy.
Here's a simpler task to consider: Split a transscript into lines. Or just: Determine the line width of a transscript (from a non-resized terminal). Problem: still suffers the same problems as above. In the end, there's only a single known '100% perfect' use of a (timed) transcript: replaying on the very same terminal with the same initial settings and size... .
In the end, the script command is surprisingly useless... . Some other tools also provide means for dumping a scrollback buffer, e.g. xterm or screen (which also suffers the line width guessing issue, but at least doesn't contain escapes).