[nos-bbs] Screen dump info

[George (Skip) VerDuin]

Way back in November, Maiko and I briefly discussed ways to capture
screen material for documentation and debug purposes.
I now have something of an answer - and I promised to pass my findings
back...?

My standard mode of operating (on Linux FC-4) is to:
  A) init jnos from root (#) on multi-session "F2" so I have a separate
jnos console immediately available
  B) use jnos from user ($) thru a telnet session from multi-session
"F5" (as my normal uid)
  C) use the GUI tools for most everything else on multi-session
"F7" (as a normal uid)
I don't have jnos established as a service for 24/7 operation (yet)
since radio availability is an issue and sometimes the TNC needs TLC if
there has been power interruption.  I often trace interface traffic
using standard jnos features and catalog the results for back-tracking
purposes.

In order to capture operator interface data for documentation (and when
things go wrong), I found a couple ways that function pretty well.  I
find them most useful as I replicate problems since malfunctions are
fairly infrequent, and so I don't always operate with the following
stuff in place.  After capturing the problem thru reenactment, I find it
pretty easy to use my favorite text editor to select the portion of the
screen text that relates to the bug, and prepare a file to use as an
email attachment.

My favorite is to capture using "tee", a Linux (Unix) basic utility.  To
load the file "screen.txt" with screen data, use the command:
      ...$ telnet 192.168.2.2 | tee screen.txt
After telnet exits, edit the screen.txt file as needed to display what
was seen during the session.  One caveat - the command line echos (that
I type) are missing from the output.  All-in-all, this works pretty well
to collect text for documentation purposes - I use it to help me
remember details about remote stations.

My second favorite for deeper analysis in HEX when special characters
are the culprit, telnet has a built-in trace facility.  There is a
utility to re-display the hex data in character form, but I have not
needed it to date.  If the plan is to capture data, then:
      ...$ telnet 192.168.2.2 -n screen.dump
While in the session and before the problem, escape and enable the trace
with:
      ^]
      telnet> toggle netdata
After the problem (presuming telnet has not crashed) repeat the above to
stop collection.  After the session is complete then edit the file
"screen.dump" with that favorite editor.  When there is a surprise, and
the "-n file" paramater is not given to telnet upon start-up, the file
may be set during the session by:
      ^]
      telnet> set tracefile screen.dump
That needs to be done before toggling netdata to keep the trace data off
the screen.  There are more options to this found in the man pages for
telnet.

My third favorite requires root (#) user, so I don't do it often...
Quoting Maiko:
" I found this a short time ago - 

http://www.faqs.org/docs/Linux-HOWTO/Keyboard-and-Console-HOWTO.html#s20

I hope that helps. "
This uses the command:
      ...# setterm -dump 5
In this case, I use the "F1" console as root to issue the command to
capture the text existing at the moment on console "F5".  This works
when finding a suspected condition to document (the condition fits one
screen full or less) and the screen stops scrolling and the user can
skip over to another multi-console to do the capture...  This does not
trace, it snapshots the screen and places the content into the file
"screen.dump".  Again my favorite editor helps me make a "show-and-tell"
display for whatever purpose.
NOTE: I have found the normal user can also do this BUT it must be
preceeded by a su and chmod to set /dev/vcsa5 with o+rw permissions.

I hope someone else finds this useful...


73
de Skip k8rra k



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060219/0e6adcdd/attachment.html>