home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / apollo / 3543 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  1.2 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!cel.cummins.com!philip
  2. From: philip@cel.cummins.com (Philip D. Pokorny)
  3. Newsgroups: comp.sys.apollo
  4. Subject: Re: strange program behavior
  5. Message-ID: <9209151905.AA04572@cel.cummins.com>
  6. Date: 15 Sep 92 19:05:15 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 18
  10.  
  11. Thanks for all those that responded with suggestions on how a program might
  12. write to the pad after a vt100 emulator was started on-top of it.
  13.  
  14. The vendor selling the software found the problem.  It seems that they were
  15. dup() ing  the stdout stream and then latter calling tgetent (a termio
  16. initialization routine)  It appears that tgetent tests to see whether stdout
  17. is a DM PAD and if so, starts a vt100 window on the pad and then REPLACES
  18. stdout with a connection to the vt100 pty.  Because the product dup'd stdout
  19. and was writing to the old stream, the output was going to the pad and not
  20. the vt100 emulator.  Moving the tgetent call before the dup solves the problem
  21. as does not dup'ing stdout at all.
  22.  
  23. Thanks again for the input.
  24.  
  25. Sincerely,
  26. Philip D. Pokorny
  27. philip@cel.cummins.com
  28. :)
  29.