dave@utcsrgv.UUCP (Dave Sherman) (11/23/83)
A couple of weeks back I posted a question asking for the best
way of counting lines transmitted between student and computer
in a CAI session, so I can figure out what Datapac usage will cost.
I ended up simply hacking stdio - it turned out to be quite easy.
Along the way, though, I got a number of interesting suggestions
that are worth sharing with the net.
Thanks to utcsstat!ian, hou3c!ka, utcsstat!laura, cbosgd!mark, stolaf!vtl,
hammer!steveh, and utcsrgv!dudek for suggestions.
Here they are:
===========================================================================
I's suggest that you start with iostat -t, which gives you (a, system-wide only)
a good measure of ttyin and ttyout. Run the thing single user, and do
iostats during it into a file.
===========================================================================
Hacking stdio should be pretty simple. All the reads and writes done
by stdio are in the rouines _fillbuf and _flsbuf, respectively, so you
can count the newlines in these routines. (Actually, that may be _filbuf
with one 'l'.) At any rate, all you need are your own copies of these
two routines, and possibly fflush as well. (Fflush is in the same file
as _flsbuf.)
===========================================================================
If you are fgoing to have to count chars to see when to put in a CR,
then you can just count the CRs that you put in which should give you
a pretty rough idea how much the user typed. Youc an count user-typed
CRs the same way you are going to have to for the letter count business
===========================================================================
Grab a copy of /usr/src/cmd/script.c from your Berkeley VAX - that
may do what you need. You can count cr's there. You might have
to do some setbuf(stdout, NULL)'s in your code to make it work
under script - if nothing gets flushed until too late this is
the problem.
Hacking stdio won't be hard, but will slow things down a lot
since putc/getc are macros.
===========================================================================
The hack to the tty driver would be pretty easy, just add a field to the
ac structure for line_delimiters_received and keep track of it with the normal
per-process accounting. This would involve hacking a couple of kernel
files and sa. The disadvantages would be that you have to "unhack" the kernel
and that your accounting files would be incompatible with the ones created
before and after (this matters if you save them forever). We did a similar
thing to keep track of lp paper (clearly we couldn't hack *all* the commands).
My vote is for a second stdio.h. The only problem here is you don't have a
clear way to save the information (every program needs to be changed unless
you modify exit() to write out your information....) and there is no record
locking when you do write it out.
===========================================================================
There is always the hardware method:
1) hook up a serial line analyzer and have it trigger on a preset character,
and count it.
2) wire a simple circuit to look for any char u want.
Uart/baud rate gen/8 bit comparator
then hook it up to a counter.
===========================================================================
An accounting (sa) record is written out each time a process dies. It doesn't
matter if you run a shell or not. All you have to do is look for the name of
the process in the output (probably an option...).
Another alternative is buy (or rent) a "network line analyzer". I read about
one of these in datamation last night (ad, not article). I guess they've been
around for years and some of the more advanced models will give you character
counts, line delimiter counts and so on. They looked like megabucks, but you
may be able to rent or borrow one from a terminal/network dealer.
===========================================================================
Could you not pipe all I/O to/from the login shell through
a filer like wc? Then, anything the user runs will automatically
have stdout/in attached to your filters.
The only glitch is that the shell will then have to be told
explicitly that it is in interactive mode ( -i flag, I think), otherwise
it won't print any prompts. Also, some programs that use "isatty"
(does that exist on V7? I forget.) may behave oddly.
I used to have a line like:
exec xlate | sh
in my .profile to do character translation for a weird terminal I had.
===========================================================================
I'll post my stdio changes in a separate article.
Dave Sherman
The Law Society of Upper Canada (utcsrgv!lsuc!dave)
Toronto
--
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!dave