|
in reply to Wanted: humanly readable `script` output
Thank you ikegame and shmem for your replies. You both seemed to be asking what do I want this for. Indeed from your responses I see I forgot to state clearly what criteria I'm looking for in a solution.
I want a file which (1) is a snapshot (ignoring color and font type) of the terminal at a given moment in time (rather than a movie, which is what script captures.) and (2) as if the terminal had no buffer size limitation, (3) is editable and searchable with a text editor, (4) is the output of a command-line program, not the result of copy/pasting with a mouse.
Up to now, my usual practice has been to copy/paste stuff from a terminal into an emacs buffer using a mouse. I lose coloring and bold face text, but I obtain a snapshot that respects erased characters and cursor positioning up to a certain point in time. That satisfies criteria (1) and (3), but not (2) and (4).
Thank you all very much for your thoughtful suggestions, but due to my inaccurate description of what I'm looking for, none of the suggestions so far meet my criteria. |
Re^2: Wanted: humanly readable `script` output
by 5mi11er (Deacon) on May 06, 2008 at 14:25 UTC
|
Both ikegame and shmem also explained that what you are looking for isn't easily done. Yes perl (or any other language) can do it, and you're barking up the right tree looking at Term::Cap if you're determined to pursue actually creating this beast.
Let me attempt to shed some light on why this problem is "hard". If you look at your local linux /etc/termcap file, this is the configuration file for all the myriad "terminals" that have ever existed. By using libraries and this configuration file, it is possible to create your own display engine, and this is roughly how all the terminal emulation program(s) you might use all work; whether that is putty, SecureCRT (my fav.), or xterm (or not) on the unix console.
In my local copy there are over 1500 lines with terminal names/types. So, if you want this to be truly robust you have to be able to handle all those terminal types. Not easy, but with the help of libraries and the termcap file, it isn't as large a mountain as it might seem; but it's certainly not child's play.
Now, in your favor is the fact that in the real world, you're typically only going to care about a small subset of terminals, namely vt100/200/220 and xterm. Those are defacto standards today, but Linux and ANSI are two others that might also be widely used. That's still 6 different terminal protocols you have to deal with 100% correctly in order to be robust.
If you're still determined to sink a lot of time into this, the Putty source code is available, I suggest using that as a guide. Good luck. -Scott
| [reply] |
Re^2: Wanted: humanly readable `script` output
by kings (Sexton) on May 06, 2008 at 04:04 UTC
|
| [reply] |
Re^2: Wanted: humanly readable `script` output
by shmem (Chancellor) on May 27, 2008 at 22:04 UTC
|
(1) is a snapshot (ignoring color and font type) of the terminal at a given moment in time (rather than a movie, which is what script captures.)
A snapshot is a still image of a movie. The movie is typescript. The scriptreplay I posted fetaures pausing and continuing the script replay with a space bar press. There's your snapshot; there is no oher way, since terminal output has more about than color - size, movements and erasing.
You cannot get at some movie snapshot without scrolling through it. For fast scrolling, hit the + key which will increase the divisor; to slow it down, hit the - key.
(2) as if the terminal had no buffer size limitation
The buffer grows and shrinks. Is the buffer state to be considered before or after a user hit <Ctrl>L or typed "clear"? The buffer also remains static while copious typing is sent to the terminal - e.g. editing text with vi. No scrollback buffer involved, it all happens at the same buffer location.
(3) is editable and searchable with a text editor, (4) is the output of a command-line program, not the result of copy/pasting with a mouse.
Your wish (3) cannot be fullfilled, since terminal output isn't text - it's not linear. A terminal is a screen area in time. Take command line editing, going back and forth inserting and deleting chars. At which moment in time is the searched text ready to be found? Wrt (4), any command line tool which converts terminal output into streaming text will produce something between "clean text" where significant information might be lost, and the "garbage" typescript recorded.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |
|
|
