home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / linux / 7086 < prev    next >
Encoding:
Text File  |  1992-07-30  |  1.4 KB  |  36 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!destroyer!gumby!yale!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!daemon
  3. From: f6930910@scheme.cs.ubc.ca
  4. Subject: catting binaries
  5. Message-ID: <1992Jul31.044152.18121@athena.mit.edu>
  6. Sender: daemon@athena.mit.edu (Mr Background)
  7. Reply-To: f6930910@scheme.cs.ubc.ca
  8. Organization: The Internet
  9. Date: Fri, 31 Jul 1992 04:41:52 GMT
  10. Lines: 24
  11.  
  12. Hi.  Here is something for you to try at home.  I often go looking
  13. for stuff in directories by using 'grep stuff *'.  This is not
  14. really all that bright of me, because sometimes stuff happens to be
  15. in an executable or library or other such binary in that directory, 
  16. in which case my screen gets rapidly filled with binary nonsense.
  17.  
  18. The wierd thing is that sometimes (not allways), after all the
  19. garbage has been cat(ed) to the screen, the terminal is left in
  20. a state such that all characters echoed to the screen are displayed
  21. as IBM extended graphics characters.  This does not allways happen, but
  22. usually does.  To see this, just cat a few of your favorite binaries
  23. to stdout.
  24.  
  25. My question then becomes:  How do I get the terminal back into a
  26. normal state?  stty sane < /dev/tty1 > /dev/tty1 does no good.
  27. Why would this happen anyway?  BTW, catting a binary in an xterm
  28. never seems to do any harm -- only when on a virtual console.
  29.  
  30. I am using 0.96cp2, the new setterm, etc, etc..
  31.  
  32. Many thanks.  Even a "it sure doesn't do that on my machine" would
  33. be helpful.
  34.  
  35. -Ken
  36.