cole@unix.SRI.COM (Susan E. Cole) (02/27/88)
I like UNIX better than Tops-20, really, but there are two Tops-20 capabilities that I wish I could get on my Pyramid system. One is "advise", which allows a user on one tty, with permission, to share control of another's tty line. User A "advises" user B. Then input to user B's job can be given from either person's terminal, and output for B goes to both terminals. This is very handy for telephone consulting -- clears misunderstandings up fast. The other capability I'd like is called "trap file openings" on Tops-20. Once you set this feature on, the system announces every file open done on your behalf (and whether it is for reading or writing). This can also clear up confusion real fast -- "it's looking in THAT directory?!" If anyone knows how to implement these features on UNIX, whether with public domain or purchased software, please post or mail. Thanks very much! -- - Susan Cole USENET: ...!hplabs!sri-unix!cole ARPA: cole@unix.sri.com
lm@arizona.edu (Larry McVoy) (02/27/88)
In article <12970@sri-unix.SRI.COM> cole@sri-unix.ARPA (Susan E. Cole) writes: >One is "advise", which allows a user on one tty, with permission, to >share control of another's tty line. User A "advises" user B. Then >input to user B's job can be given from either person's terminal, >and output for B goes to both terminals. This is very handy for >telephone consulting -- clears misunderstandings up fast. I wrote something like this once. Basically you need to setup two pty pairs, such that the front side of each pair is running on each terminal. Then the program that hooked all this up spawns a sh/csh/ksh and sends all the input to the shell and all the output back to either pty. It's a drag but it can be done. >The other capability I'd like is called "trap file openings" on Tops-20. >Once you set this feature on, the system announces every file open >done on your behalf (and whether it is for reading or writing). This >can also clear up confusion real fast -- "it's looking in THAT directory?!" You can't do this without either a) modifying the kernel or b) recompiling all appropriate code. If someone can prove me wrong, I'd like to hear it too. -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm Use the force - read the source.
aj@zyx.UUCP (Arndt Jonasson) (03/06/88)
In article <12970@sri-unix.SRI.COM> cole@sri-unix.ARPA (Susan E. Cole) writes: >I like UNIX better than Tops-20,really, but there are two Tops-20 capabilities >that I wish I could get on my Pyramid system. > ... >The other capability I'd like is called "trap file openings" on Tops-20. >Once you set this feature on, the system announces every file open >done on your behalf (and whether it is for reading or writing). This >can also clear up confusion real fast -- "it's looking in THAT directory?!" Of course, this can't be implemented with the full generality of the Tops-20 Set Trap File-Openings without changing the kernel, but your question inspired me to investigate what could be done with 'ptrace'. It took me a day and I now have a program that is invoked as e.g. 'trapfile myprog foo bar'. It will then run 'myprog foo bar', while displaying all calls to 'open' and 'close' on stderr. It makes very heavy use of 'ptrace' and is thus fairly unportable (I use HP-UX on a 68020) and it doesn't work for programs that fork and then use 'open' or 'close', although that could be fixed (so that they don't crash, that is - there can't be any tracing output for the forked processes). It doesn't make any use of any symbol table that myprog might have, although that would make it a little faster to find the 'open' and 'close' calls. If this program is going to be at all useful remains to be seen, but this shows that it can be done. -- Arndt Jonasson, ZYX Sweden AB, Styrmansgatan 6, 114 54 Stockholm, Sweden email address: <backbone>!mcvax!enea!zyx!aj = aj@zyx.SE