home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / wizards / 4643 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  1.4 KB
  1. Xref: sparky comp.unix.wizards:4643 comp.unix.shell:4666 comp.unix.misc:4131
  2. Path: sparky!uunet!ogicse!reed!kanderso
  3. From: kanderso@reed.edu (Karl Anderson)
  4. Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
  5. Subject: Re: The Problem with UNIX
  6. Message-ID: <1992Nov12.204710.5808@reed.edu>
  7. Date: 12 Nov 92 20:47:10 GMT
  8. Article-I.D.: reed.1992Nov12.204710.5808
  9. References: <1992Nov9.172715.16367@cs.wisc.edu> <aldavi01.721333614@starbase.spd.louisville.edu> <1992Nov11.194557.16258@yarc.uucp>
  10. Organization: Reed College, Portland, OR
  11. Lines: 18
  12.  
  13. In article <1992Nov11.194557.16258@yarc.uucp> scott@yarc.UUCP (Scott Beckstead) writes:
  14. >
  15. >  I think this is kinda what he is trying to determine.  Typicaly UNIX
  16. >imposes far more structure on the user than is desired.  I agree an
  17. >experienced user should be able to recognize and avoid the problems
  18. >above.  What's wrong with the shell catching such obvious errors and
  19. >either reporting them or taking other appropriate action (ie correcting
  20. >them).  I realize that this will get me screamed at by all you guru
  21.  
  22. Is there any reason why there can't be another stream for more
  23. user-friendly messages?  We have stdin and stderr, why can't there be
  24. a standard verbose stream as well?  Experienced users could just
  25. direct it to /dev/null , or, to save cpu time, could have a flag that
  26. would disable it altogether.
  27.  
  28. k
  29.  
  30. >Reply to: scott@yarc.uucp     |  
  31.