root@ozdaltx.UUCP (root) (09/09/87)
A while back I'd asked if anyone has an effective tty watcher or "spy" program, or if they had suggestion as to how such a thing could be accomplished. The most common reply was; use 'cat < /dev/ttyxx', good idea, but the I/O gets confused and can't quite figure out where things are supposed to go. Several versions of *NIX must have had a "hook" or stub in the kernal as more than one person made mention of a 'spy' program that effectivally let you tune in on some one elses tty. To make a long story short, appearently it just can't be done. Looks like MS-DOS wins this round. Thanks for all the reply and suggestions. -- ============================================================ | Scotty | Adapt - Enjoy - Survive | | ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | ============================================================
dyer@spdcc.COM (Steve Dyer) (09/10/87)
It seems to me that you might be able to hack something up with a
new line discipline which paralleled the normal tty line discipline
with the exception that it replaced the l_input routine with one which,
before calling the standard l_input routine, enqueued its characters
on a private clist of a special device which could be read by the
'spy' program.
Another alternative is to take the public domain pty driver posted recently
and have your gettys running on the pty slaves instead of the serial lines
directly. You would then have a 'telnetd'-like process reading and writing
to the pty controller and the serial device. It could perform the logging
at that point in user mode.
None of these solutions are "free" without requiring some kernel work.
However, the pty solution is pretty simple to implement.
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyerjosh@hi.UUCP (Josh Siegel) (09/10/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >A while back I'd asked if anyone has an effective tty >watcher or "spy" program, or if they had suggestion as to >how such a thing could be accomplished. Must have missed this posting... sorry. > >The most common reply was; use 'cat < /dev/ttyxx', good >idea, but the I/O gets confused and can't quite figure out >where things are supposed to go. Very true. Not a good idea. There are lots of better ways of doing this. > >Several versions of *NIX must have had a "hook" or stub in >the kernal as more than one person made mention of a 'spy' >program that effectivally let you tune in on some one elses >tty. It does exist in many forms... 1) Stealbuf - This code reads the input buffers of the user being watched and prints out everything he/she is typing. It doesn't work if they are in raw mode. I don't know who wrote it. 2) Spy - Kinda like a running ps. Fast and clean. Lets you see what commands a user is running. I don't know who wrote it. 3) eye - This is the gem of the bunch. Written for a Sun computer, it watches TCP/IP connections on the ethernet. This lets you see exactly what a user is doing... both input and output. Also, it lets you keep a transcript of the conversation. Triggers exist on it to start watching a connection when the user types "su\n" and when a connection starts up. Very useful for breaking into computer systems and watching what others are doing at any given time. I wrote this one.... > >To make a long story short, appearently it just can't be >done. Looks like MS-DOS wins this round. I am not sure what it won. Sorry... looks like Sun won again ;-) > >============================================================ >| Scotty | Adapt - Enjoy - Survive | >| ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | >============================================================ Before I get mail asking me for copies of the software, let me state my policy. I will not pass out stealbuf or eye to anybody. Stealbuf doesn't work on BSD43 and eye only works on Suns. The current version of eye is nothing but a machine cracker. I don't see a reason to pass this around. In a few weeks, I plan on posting a new version of eye that is a ethernet debugger. I never plan on posting my cracking version. -- Josh Siegel (siegel@hc.dspo.gov) Friends don't let Friends eat Cherry Zingers
kathy@bakerst.UUCP (Kathy Vincent) (09/11/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >A while back I'd asked if anyone has an effective tty >watcher or "spy" program, or if they had suggestion as to >how such a thing could be accomplished. > >To make a long story short, appearently it just can't be >done [ in *NIX ]. Looks like MS-DOS wins this round. Rather depends what your idea of "winning" is, doesn't it? I'd be just as glad to know you couldn't spy on what I was doing - and, no, I don't have anything to hide. Ergo, in my opinion, *NIX would win the round. Kathy Vincent ------> Home: {ihnp4|mtune|codas|ptsfa}!bakerst!kathy ------> AT&T: {ihnp4|mtune|burl}!wrcola!kathy
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/12/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes:
<A while back I'd asked if anyone has an effective tty
<watcher or "spy" program, or if they had suggestion as to
<how such a thing could be accomplished.
Must have missed it; or ignored it assuming that somone more
knowledgeable than I would answer.
<Several versions of *NIX must have had a "hook" or stub in
<the kernal as more than one person made mention of a 'spy'
<program that effectivally let you tune in on some one elses
<tty.
Don't recall having seen them, but can easily believe it. But there's
a better way.
<To make a long story short, appearently it just can't be
<done.
It can be done. The trick is to wade through the kernel data
structures in /dev/kmem until you find where incoming characters from
that tty are being stored, and then watch that space. A program to do
this on 4BSD made the rounds about 3 years ago, causing a flurry
chmod 540 /dev/*mem* /vmunix
chgrp kmem /dev/*mem* /vmunix /bin/ps <and similar things>
chmod 2711 /bin/ps <and similar things>
commands to be issued
<Looks like MS-DOS wins this round.
When did MS-DOS start supporting multiple users so that such a thing
would make sense?
<mike
--
When logic and proportion have fallen soggy dead, Mike Meyer
And the white knight is talking backwards, mwm@berkeley.edu
And the red queen's on her head, ucbvax!mwm
Remember what the dormouse said. mwm@ucbjade.BITNETalvitar@madhat.UUCP (Phil Harbison) (09/12/87)
In article <249@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: > It seems to me that you might be able to hack something up with a > new line discipline which paralleled the normal tty line discipline > with the exception that it replaced the l_input routine with one which, > before calling the standard l_input routine, enqueued its characters > on a private clist of a special device... This is similar to my implementation of a journal feature on a piece of UNIX-based test equipment at Boeing. The Air Force wanted a journal of every keystroke (before input processing) so they could study human factors and write better user interfaces. Each character was put in the raw queue and a copy was also placed in a clist owned by the journal driver if /dev/journal was open. This would be a trivial hack to almost any tty driver. -- Live: Phil Harbison USPS: 3409 Grassfort Drive, Huntsville, AL 35805-5421 Uucp: {clyde,uunet}!madhat!alvitar Bell: 205-881-4317, 205-837-7610x546
jhc@mtune.ATT.COM (Jonathan Clark) (09/12/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: :A while back I'd asked if anyone has an effective tty :watcher or "spy" program, or if they had suggestion as to :how such a thing could be accomplished. This sounds lie a 3-line stream module to me. What's the problem? In article <15136@hi.UUCP> josh@hi.UUCP (Josh Siegel) writes: : 3) eye - : This is the gem of the bunch. Written for a Sun : computer, it watches TCP/IP connections on the : ethernet. This lets you see exactly what a user : is doing... both input and output. Also, it : :I am not sure what it won. Sorry... looks like Sun won again ;-) You mean that Sun doesn't offer end-to-end encryption? What a piece of junk :-) -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
guy@sun.UUCP (09/12/87)
> :A while back I'd asked if anyone has an effective tty > :watcher or "spy" program, or if they had suggestion as to > :how such a thing could be accomplished. > > This sounds lie a 3-line stream module to me. What's the problem? 1) Few, if any, kernels currently have streams-based tty drivers; S5R3 and S5R3.1's standard tty drivers aren't streams-based. 2) Streams modules live in the kernel, and not everybody can stuff an arbitrary streams module into their kernel. The tty watcher in question requires *some* kernel hacking (unless the vendor of your system has already done that hacking) even with a streams tty. 3) There is no such thing as a non-trivial 3-line streams module. :-) 2) is the major point here; there are no tty watchers that consist solely of a user-mode program that drops on top of a non-hacked UNIX system. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
tim@amdcad.AMD.COM (Tim Olson) (09/14/87)
In article <27816@sun.uucp> guy@sun.uucp (Guy Harris) writes: +----- | > :A while back I'd asked if anyone has an effective tty | > :watcher or "spy" program, or if they had suggestion as to | > :how such a thing could be accomplished. | > | 2) Streams modules live in the kernel, and not everybody can stuff an | arbitrary streams module into their kernel. The tty watcher in question | requires *some* kernel hacking (unless the vendor of your system has already | done that hacking) even with a streams tty. +----- What about a new getty which, instead of exec'ing the user's shell, forks the shell with a pseudo-tty as a terminal, then "watches" the real terminal, sending the characters received & sent both to the pseudo-tty as well as to the snooper? That wouldn't involve hacking the kernal at all.
guy@sun.uucp (Guy Harris) (09/14/87)
> What about a new getty which, instead of exec'ing the user's shell, > forks the shell with a pseudo-tty as a terminal, then "watches" the real > terminal, sending the characters received & sent both to the pseudo-tty > as well as to the snooper? That wouldn't involve hacking the kernal at > all. Unless, of course, your kernel lacks pseudo-ttys.... This also requires you to hack "getty", although you could have the pseudo-"getty" set up the pseudo-tty and run the real "getty" immediately, thus obviating the need to duplicate all of "getty"'s functionality (painful to do without source). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
jhc@mtune.ATT.COM (Jonathan Clark) (09/14/87)
In article <27816@sun.uucp> guy@sun.uucp (Guy Harris) writes: >I wrote: >> This sounds like a 3-line stream module to me. What's the problem? > >1) Few, if any, kernels currently have streams-based tty drivers; S5R3 and >S5R3.1's standard tty drivers aren't streams-based. Well, I *was* being more than slightly facetious when I wrote that comment, although I think you could actually do the guts of it in close to three lines: /* output */ /* input */ mblk_t *dup; mblk_t *dup; dup = copymsg(mp); dup = copymsg(mp); putnext(up_to_monitor,dup); putnext(up_to_monitor,dup); putnext(down_to_device,mp); putnext(up_from_device,mp); [ I'm doing this from memory so the declarations &c may be wrong. ] A small amount of footling around to set this up would be needed, and the surrounding stream module code should be added, but it should be that simple. Unfortunately Guy is absolutely correct about the SVR3 and 3.1 tty drivers not being streams-based and hence this approach not being terribly useful. Perhaps some day this will come to pass (or we'll convert to v8). You could even stick this either above or below the line discipline module, depending on whether you wanted raw characters as typed or what gets passed up the the user process. >2) Streams modules live in the kernel, and not everybody can stuff an >arbitrary streams module into their kernel. True, alas, although one can in all the SVR3-based systems. Errr, can't you? >3) There is no such thing as a non-trivial 3-line streams module. :-) Right again! This one *is* trivial! >2) is the major point here; there are no tty watchers that consist solely of a >user-mode program that drops on top of a non-hacked UNIX system. Yup. This is the type of problem which *ought* to be simple but which isn't in a non-streams environment. Streams was created to be able to handle this sort of thing - following the example above, it succeeds. -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
guy@sun.uucp (Guy Harris) (09/15/87)
> although I think you could actually do the guts of it in close to three > lines: > > /* output */ /* input */ > mblk_t *dup; mblk_t *dup; > dup = copymsg(mp); dup = copymsg(mp); > putnext(up_to_monitor,dup); putnext(up_to_monitor,dup); > putnext(down_to_device,mp); putnext(up_from_device,mp); Unfortunately, this means that *everything* going up and down the stream gets sent upstream, if you intend this to be implemented by 1) a streams module that get stuck in above the rest of the tty driver, and 2) a streams driver that implements the tap, with the two joined at the hip. This means that flush messages sent upstream or downstream will also flush the monitor, M_HANGUPs and M_ERRORs will wedge the monitor's stream, M_SIGs and M_PCSIGs will send signals to the monitoring process, etc.. It's straightforward enough to duplicate only the interesting messages with a switch statement, but it does increase the line count a bit more.... (I presume the two "putnext(up_to_monitor, ...)" calls go to different major devices, so that you can distinguish input from output. If not, the complexity goes up a bit more, as the messages need to be stamped to indicate whether they're input or output data.) > >2) Streams modules live in the kernel, and not everybody can stuff an > >arbitrary streams module into their kernel. > > True, alas, although one can in all the SVR3-based systems. Errr, can't you? Well, yeah, it's only a Simple Matter of Programming (you have to have the module first before you can insert it). You also have to have a kernel distributed as a bunch of object modules, rather than as a single executable; I could imagine some packaged systems supplying a prebuilt kernel or kernels. > >2) is the major point here; there are no tty watchers that consist solely > >of a user-mode program that drops on top of a non-hacked UNIX system. > > Yup. This is the type of problem which *ought* to be simple but which isn't > in a non-streams environment. Streams was created to be able to handle > this sort of thing - following the example above, it succeeds. Umm, no, it doesn't. I said "consist(s) *solely* of a user-mode program that drops on top of a *non-hacked* UNIX system." If the tee-junction streams module is in your kernel, then unless your vendor or some third party supplied it, either it had to be hacked up locally for some other purpose (in which case you don't have a non-hacked UNIX system) or it's part of the tty watcher (in which case it doesn't consist solely of a user-mode program. A streams-based tty driver would definitely make it much *easier* to insert this capability, since you wouldn't need to hack the tty driver code itself (which would require source in most, if not all, cases), but it still requires you to stuff code into your kernel. At some point, some vendor may, indeed, offer this streams module; however, until then, implementing a tty watcher requires kernel hacking (which, in turn, generally requires a kernel hacker). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
root@ozdaltx.UUCP (root) (09/15/87)
WoW! I didn't realise I was going to get something started when I wanted a tty watcher. :-). First let me explain my needs/purpose/OS. + I have users that call via modem. Occasionally they get stuck and often can't (or won't) understand the error message they are getting. So it would be nice to watch them and try to see whats wrong. + I'm running SCO XENIX System V on a "clone". Now I know the kernal could be hacked. I don't have the expertise in this area to attempt such a 'fool-hardy' thing. I can make awk play music, but device drivers are a little specialized. When I made the comment, "MS-DOS wins this round"; the true but unfortunate fact of life is that DOS's capibility for "host mode" is very simple to access. As is any other port in the OS. Also, lets face it people, *NIX is not winning any awards for user friendliness. I personally love it, but most users, (not hackers/programers/gurus, etc) want to be able to push a button and not worry about syntax, flags, pipes or redirects. Have you ever considered how cryptic and difficult the "stock" E-mail program is to use? -- ============================================================ | Scotty | Adapt - Enjoy - Survive | | ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | ============================================================
brianc@cognos.uucp (Brian Campbell) (09/15/87)
In article <5070@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike Meyer) writes: ! In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: ! <A while back I'd asked if anyone has an effective tty ! <watcher or "spy" program, or if they had suggestion as to ! <how such a thing could be accomplished. ! ... ! <Looks like MS-DOS wins this round. ! ! When did MS-DOS start supporting multiple users so that such a thing ! would make sense? Well, although the posted message didn't specifically mention it, the original question related to watching what callers were doing on a BBS. [The reply-to field (sysop) hinted at this]. Since there are a number of BBS's running under MS-DOS, and it is quite simple to trap all incoming and outgoing characters, I guess MS-DOS just might have won this round. -- Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc Cognos Incorporated mail: POB 9707, 3755 Riverside Dr., Ottawa, ON, K1G 3Z4 (613) 738-1440 fido: sysop@163/8
dyer@spdcc.COM (Steve Dyer) (09/16/87)
This is silly. A BBS program running under DOS doesn't automatically
"come with" the ability to display what a user has been typing; it has to
be designed that way, especially if the sysop and the user are going
to both be typing at the same time (illusion of multi-programming.)
As far as I can see, DOS or the BBS program would require just as much
hacking to get it to display what you the user types; difference is,
most single purpose BBS already come with this feature. I would be surprised
if you, as an example of "most users", could hack your version of DOS or
its serial driver to make it do what you want. One point must be conceded,
namely, that because of the economics of the DOS world and the simplicities
of the DOS programming model, you are much more likely to find such a feature
available already for sale. This isn't true for Xenix or any other UNIX.
If you needed user typein monitoring within the context of a UNIX-based
BBS system, then of course, there'd be no need for kernel hacking or
special device drivers--the program could be designed to allow monitoring
to a file upon receipt of a signal, or perhaps use some IPC feature of Xenix.
However, given that you wanted the ability to see what the user is typing at
any time, within any program, then one of the suggested kernel-based solutions
is necessary. This hardly seems unreasonable. Of course, the same DOS
model, namely, assigning the console to be COM1, is even less flexible since
you, the operator, would be unable to do anything without a reboot!
It's too bad that, instead of pursuing some of the solutions, you dismiss them
out of hand. It always takes one pioneer to take the risk so that the next
person who needs the same solution can get it "off the shelf."
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyermikel@flmis06.ATT.COM (Mikel Manitius) (09/17/87)
>2) is the major point here; there are no tty watchers that consist solely of a >user-mode program that drops on top of a non-hacked UNIX system. I saw this done on 4.1bsd once, I even had the code that did it. It was a simple program that figured out where the clist struct was for that user's tty driver, and scanned it repeatidly in /dev/kmem for changes. It would output his input line by line. This sort of thing should be feasable on most Unix systems... It's just a pain figuring out where to find his clist, especially given just a tty name. -- Mikel Manitius @ AT&T Network Operations mikel@codas.att.com.uucp | attmail!mikel
terryl@tekcrl.TEK.COM (09/18/87)
In article <198@flmis06.ATT.COM> mikel@flmis06.ATT.COM (Mikel Manitius) writes: >>2) is the major point here; there are no tty watchers that consist solely of a >>user-mode program that drops on top of a non-hacked UNIX system. > >I saw this done on 4.1bsd once, I even had the code that did it. It was >a simple program that figured out where the clist struct was for that user's >tty driver, and scanned it repeatidly in /dev/kmem for changes. It would >output his input line by line. > >This sort of thing should be feasable on most Unix systems... It's just >a pain figuring out where to find his clist, especially given just a >tty name. Actually, if you have a tty name, it is quite trivial to figure out where the C-list structure lives in kernel memory (assuming you have at least read access to /dev/kmem). ****WARNING, WILL ROBINSON!!! SPOILER AHEAD!!!**** It goes like this: first, do a stat(2) on said tty name. Inside of the stat structure returned is a field giving the major/minor number of the tty. Take the major number and use this to index into the cdevsw[] structure. One of the fields in the cdevsw[] structure is a pointer to the FIRST tty structure for the specific RS-232 device. Now use the minor number gotten from the stat(2) call to index into the tty structure. You now have a pointer to the tty structure for the tty name in question. It is left as an exercise to the student to find the appropriate C-list struc- ture. Terry Laskodi of Tektronix
jfh@killer.UUCP (09/18/87)
i'm sure this has been thought of before to solve this problem, but what is wrong with re-writing the /dev/tty driver (i seem to recall the source is very short and simple) so that the minor device number is passed from the open/close/read/write/ioctl calls rather than snatched out of the u-page? you would have your hands on all of the data passed back from the actual calls (say, dzread()) and would then be able to stuff it into a kernel structure. this should be _very_ easy. my only problem is with the close routine as closing the ttywatcher would call the real close and it might not be ready to be closed just yet (although you could finger through the i-node table for the device) i forget the calling sequence for device drivers this week, but most of what you would have to do is pass the same arguments of to the correct routines, and snatch the returned characters from the users address space before/after the call. what am i not seeing? - john. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
martin@iris.ucdavis.edu (Bruce K. Martin Jr.) (09/18/87)
In article <15136@hi.UUCP> josh@hi.UUCP (Josh Siegel) writes: >In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >>A while back I'd asked if anyone has an effective tty >>watcher or "spy" program, or if they had suggestion as to >>how such a thing could be accomplished. > >Very true. Not a good idea. There are lots of better ways >of doing this. > True! >It does exist in many forms... > > 1) Stealbuf - > This code reads the input buffers of > the user being watched and prints out > everything he/she is typing. It doesn't > work if they are in raw mode. > > I don't know who wrote it. > ...stuff deleted... >Before I get mail asking me for copies of the software, let me >state my policy. I will not pass out stealbuf or eye to anybody. >Stealbuf doesn't work on BSD43 and eye only works on Suns. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >current version of eye is nothing but a machine cracker. I don't >see a reason to pass this around. > >-- >Josh Siegel (siegel@hc.dspo.gov) > Friends don't let Friends eat Cherry Zingers Not quite true. We have successfully modified our home-grown version of stealbuf to work on BSD4.3 (of course, I'm assuming that you can read /dev/kmem) ..bruce Bruce K. Martin Jr. UC. Davis Div of Computer Science martin@iris.ucdavis.edu --or-- {ucbvax | lll-crg}!ucdavis!iris!martin
davids@munnari.oz (David Spaziani) (09/18/87)
in article <198@flmis06.ATT.COM>, mikel@flmis06.ATT.COM (Mikel Manitius) says: > Xref: munnari comp.unix.xenix:342 > >>2) is the major point here; there are no tty watchers that consist solely of a >>user-mode program that drops on top of a non-hacked UNIX system. > > I saw this done on 4.1bsd once, I even had the code that did it. [...] > > This sort of thing should be feasable on most Unix systems... I worked with two other guys on a tty watcher for 4.2bsd. The idea was to connect the users shell to a pty, and place a transparent "switch" process between the tty and the pty. To see what the user was doing, you could connect to the switch and get a copy of all i/o. The priveledged user controlling the switch could also do nice things like commandeer the users shell, change the default shell, log the user out, or prevent logins altogether (plus a few other things). The whole thing worked, and without a single hack to the kernel. I still have the code. davids ====== =========================== UUCP: {seismo,mcvax,ukc,ubc-vision}!munnari!davids ARPA: davids%munnari.oz@seismo.css.gov CSNET: davids%munnari.oz@australia
peter@sugar.UUCP (Peter da Silva) (09/25/87)
In article <1431@cognos.UUCP>, brianc@cognos.uucp (Brian Campbell) writes: > ! <...an effective tty watcher or "spy" program, > ! <Looks like MS-DOS wins this round. > ! When did MS-DOS start supporting multiple users so that such a thing > ! would make sense? > Well, although the posted message didn't specifically mention it, the > original question related to watching what callers were doing on a BBS. > I guess MS-DOS just might have won this round. You can, of course, do the same thing on UNIX (watch what people are doing on a BBS), exactly the same way (have the BBS program echo stuff). I've seen two systems that do it (one of which not only traps the characters, but talks to called processes via pipes so you can have other programs do mail, etc, and have them echoed too). -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
root@ozdaltx.UUCP (09/25/87)
First, let thank the 30 or so folks who responded in reference of my looking for code for a tty watcher that *might* run on a XENIX system. Some of the names on the responces looked like a who's who in *NIX. However, after many "I wrote"s, "I have written"s , chest pounding and other self induced back slapping, forwarded to this site, with four or five possible exceptions, I have yet to see any genuine offers of help... either in the form of actual code or logical suggestions. Also noted that many of the responders obviously DID NOT read/understand the original question as the referenced systems ranged from Sun to MINIX (sp?) to whatever.. In other words referencing specific "flavors" of *NIX... when generic was/is needed. What has prompted this is, I have seen too many people in the same situation as I'm in. Asking honest questions and hoping for a legitimate responce. Instead I see (quite often from the same people), something to the effect of, "YOU DUMB S**T.. READ THE F***ING MANUAL... YOU SHOULD BE A GURU LIKE THE REST OF US". etc., etc., ect. This seems to be a common malady among programers. (I'm sure I've suffered the same on occasion). How about putting the ole egos out to pasture and cut the **FLAMES** to the newcommers. I once had a professor who's favorite saying was, "There is no such thing as a dumb question, unless it is never asked". To future posters, at least tell what system/version you are running. *NIX IS NOT STANDARD.... YET. We ALL started out pretty DUMB. -- ============================================================ | Scotty | Adapt - Enjoy - Survive | | ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | ============================================================