home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / hp / 13028 < prev    next >
Encoding:
Text File  |  1992-11-17  |  1.8 KB  |  37 lines
  1. Newsgroups: comp.sys.hp
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hpscit.sc.hp.com!scd.hp.com!hpscdm!cupnews0.cup.hp.com!wk
  3. From: wk@cup.hp.com (Wayne Krone)
  4. Subject: Re: HPUX 9.0 SIGWINCH on 800 series? -- was Re: hpterm resizable
  5. Sender: news@cupnews0.cup.hp.com
  6. Message-ID: <BxvzwE.4D0@cup.hp.com>
  7. Date: Wed, 18 Nov 1992 00:55:25 GMT
  8. References: <FRANL.92Nov16211347@draco.centerline.com>
  9. Organization: HP-UX Kernel Lab, Cupertino
  10. X-Newsreader: TIN [version 1.1.4 PL6]
  11. Lines: 24
  12.  
  13. Fran Litterio (franl@centerline.com) wrote:
  14. : Yes, but will applications (such as vi) at 9.0 defer to the window
  15. : size as known by the device (accessed via ioctl) over the size as
  16. : specified in LINES and COLUMNS when the two disagree?  Try this on a
  17.  
  18. No, the user specification takes precedence (at least for the two
  19. commands I checked: vi and ksh).
  20.  
  21. : If the same data (window size) is accessible via two different
  22. : mechanisms (environment variables and device ioctl()s), then
  23. : applications should use the mechanism that is least under the
  24. : influence of the user (ioctl()s).  This is just standard defensive
  25. : programming.
  26.  
  27. That's one philosophy.  Another is that if a user goes to the trouble of
  28. expressly stating a desired value for some parameter then the application
  29. should use it in preference to any default or system provided value.
  30. Defensive programming is good but perhaps it should be limited to cases
  31. of protecting application or system integrity.
  32.  
  33. Note I didn't implement any part of this functionality and the above
  34. philosophy probably has nothing to do with why vi acts the way it does.
  35. I believe this issue was discussed here previously and the implementers
  36. did post their reasoning but I've forgotten what they said.
  37.