home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / wizards / 4871 < prev    next >
Encoding:
Text File  |  1992-11-24  |  8.0 KB  |  239 lines

  1. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!sgiblab!sgigate!rutgers!cmcl2!adm!news
  2. From: postmaster@starlab.csc.com (SMTP MAILER)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Mail not delivered yet, still trying
  5. Message-ID: <34250@adm.brl.mil>
  6. Date: 23 Nov 92 22:34:04 GMT
  7. Sender: news@adm.brl.mil
  8. Lines: 229
  9.  
  10.  
  11.  ----Mail status follows----
  12. Have been unable to send your mail to <DGRAY@STARLAB.CSC.COM>
  13. for one day, will keep trying for another seven days.
  14. At that time your mail will be returned.
  15.  
  16.  ----Transcript of message follows----
  17. Date: 22 Nov 92 03:24:00 EST
  18. From: UNIX-WIZARDS@BRL.MIL
  19. Subject: UNIX-WIZARDS Digest  V17#002
  20. To: "DGRAY" <DGRAY@STARLAB.CSC.COM>
  21.  
  22. Return-Path: <unix-wizards-request@sem.brl.mil>
  23. Received: from SEM.BRL.MIL by milo.starlab.csc.com with SMTP ; 
  24.           Sun, 22 Nov 92 03:20:23 EST
  25. Received: from SEM.BRL.MIL by SEM.BRL.MIL id ab25769; 21 Nov 92 7:47 EST
  26. Received: from sem.brl.mil by SEM.BRL.MIL id aa25655; 21 Nov 92 7:29 EST
  27. Date:       Sat, 21 Nov 92 07:29:30 EST
  28. From:       The Moderator (Mike Muuss) <Unix-Wizards-Request@BRL.MIL>
  29. To:         UNIX-WIZARDS@BRL.MIL
  30. Reply-To:   UNIX-WIZARDS@BRL.MIL
  31. Subject:    UNIX-WIZARDS Digest  V17#002
  32. Message-ID:  <9211210729.aa25655@SEM.BRL.MIL>
  33.  
  34. UNIX-WIZARDS Digest          Sat, 21 Nov 1992              V17#002
  35.  
  36. Today's Topics:
  37.                      Re: Keyboard hit in C programs
  38.                  Re: Detecting if running under chroot
  39.                        Re: The Problem with UNIX
  40.       Re: The Problem with UNIX [Includes ANCIENT Usenet traffic]
  41.                        Re: The Problem with UNIX
  42.        Re: >>TAR file on tape distroyed, are files recoverable?<<
  43.                         SCCS ID Keywords problem
  44.                                Re: RPCGEN
  45.                Re: Any TeX (compilation) Gurus out there?
  46.             Problem with Window to Window commands.... HELP!
  47.                         Closing ends of pipe().
  48.                              TTYDEFS Help!
  49.                  Re: HELP! problem with tar PC <-> SUN
  50.         Verbose errors on demand - was Re: The Problem with UNIX
  51.                RESULT: comp.arch.bus.vmebus passes 227:19
  52.                     Re: Does Linux use segmentation?
  53.                            system call write
  54.  
  55. -----------------------------------------------------------------
  56.  
  57. From: walter misar <misar@rbg.informatik.th-darmstadt.de>
  58. Subject: Re: Keyboard hit in C programs
  59. Keywords: Keyboard hit, C programs, UNIX
  60. Date: 10 Nov 92 14:54:17 GMT
  61. Sender: The News System <news@rs2.hrz.th-darmstadt.de>
  62. Nntp-Posting-Host: rbhp69.rbg.informatik.th-darmstadt.de
  63. To:       unix-wizards@sem.brl.mil
  64.  
  65. In article <1dms9iINNa6m@agate.berkeley.edu>, bernt@valois (Bernt Skottun) writes:
  66. > I am in the process of adapting a C program from the PC for
  67. > the UNIX environment (for SUN 3 running SUNOS 4.1.1).
  68. > In this program it is essential that
  69. > the user be able to stop certain parts of the program
  70. > (e.g. an inner loop) by hitting the keyboard (any key
  71. > is fine) while as long as the keyboard is not touched the execution
  72. > of the program will continue un-interupted (thus a procedure
  73. > which requires, or expects, the user to type in a key stroke at certain
  74. > intervals will not do). In the DOS environment
  75. > I have been able to do this with the "kbhit()" function.
  76. > My question is: what is the equivalent function in the UNIX
  77. > environment? or how does one go about creating such a function?
  78. > Any suggestions will be very welcome. Thanks a lot.
  79. > Bernt Skottun, bernt@valois.berkeley.edu 
  80. >
  81.  
  82. Ok, since ^C is an 'any key' you only have to catch the SIGINT you
  83. get if ^C is hit.  
  84.  
  85. #include <signal.h>
  86. signal(SIGINT,function)
  87.  
  88. In function() ( prototyped as void function(void) ) the first call should
  89. be signal(SIGINT,function) because the behavior of SIGINT is reset to default
  90. by the signal-handler.
  91.  
  92. Walter
  93.  
  94. -----------------------------
  95.  
  96. From: Klaus Mueller <mueller@rbg.informatik.th-darmstadt.de>
  97. Subject: Re: Keyboard hit in C programs
  98. Keywords: Keyboard hit, C programs, UNIX
  99. Date: 13 Nov 92 16:18:18 GMT
  100. Sender: The News System <news@rs2.hrz.th-darmstadt.de>
  101. Nntp-Posting-Host: rbhp59.rbg.informatik.th-darmstadt.de
  102. To:       unix-wizards@sem.brl.mil
  103.  
  104.  
  105. In article <1dms9iINNa6m@agate.berkeley.edu>, you write:
  106. > I am in the process of adapting a C program from the PC for
  107. > the UNIX environment (for SUN 3 running SUNOS 4.1.1).
  108. > In this program it is essential that
  109. > the user be able to stop certain parts of the program
  110. > (e.g. an inner loop) by hitting the keyboard (any key
  111. > is fine) while as long as the keyboard is not touched the execution
  112. > of the program will continue un-interupted (thus a procedure
  113. > which requires, or expects, the user to type in a key stroke at certain
  114. > intervals will not do). In the DOS environment
  115. > I have been able to do this with the "kbhit()" function.
  116. > My question is: what is the equivalent function in the UNIX
  117. > environment? or how does one go about creating such a function?
  118. > Any suggestions will be very welcome. Thanks a lot.
  119. > Bernt Skottun, bernt@valois.berkeley.edu 
  120. >  
  121.  
  122. Here is a solution to this problem that not even requires to poll the the
  123. the keyboard. It uses SIGIO to get notified, but the program continues with
  124. the loop after the signalhandler  has returned. So you have to think about 
  125. leaving the loop after execution continues :).
  126.  
  127. I don't know how portable this is, my system is HP-UX. The relevant man-pages 
  128. are: termio(7) and ioctl(5).
  129.  
  130.  
  131. #include <sys/ioctl.h>
  132. #include <unistd.h>
  133. #include <signal.h>
  134. #include <stdio.h>
  135. #include <termio.h>
  136.  
  137. struct termio term_old;
  138.  
  139. void resetfiles(void) {        /* resets all terminalstat we have changed */
  140.     int arg;
  141.  
  142.     arg = 0;
  143.     if (ioctl(STDIN_FILENO, FIOSSAIOSTAT, &arg)==-1) {
  144.         perror("unset async");
  145.         exit(1);
  146.     }
  147.     if (ioctl(STDIN_FILENO, TCSETA, &term_old) == -1) {
  148.         perror("set termios");
  149.         exit(1);
  150.     }
  151. }
  152.  
  153. void handler(int dummy) {    /* handels the SIGIO */
  154.     printf("got it\n");
  155.     resetfiles();    /* clear what we have done */
  156.     exit(0);
  157. }
  158.  
  159. int main (void) {
  160.     int arg;
  161.     struct termio term;
  162.     
  163.     arg = getpid();    /* tell the keyboard _we_ want the signal */
  164.     if (ioctl(STDIN_FILENO, FIOSSAIOOWN, &arg)==-1) { 
  165.     perror("set owner");
  166.     resetfiles();
  167.     exit(1);
  168.     }
  169.  
  170.             /* tell the system we want a _signal_ */
  171.  
  172.     arg = 1;
  173.     if (ioctl(STDIN_FILENO, FIOSSAIOSTAT, &arg)==-1) {
  174.     perror("set async");
  175.     resetfiles();
  176.     exit(1);
  177.     }
  178.  
  179.         /* keep the old stats */
  180.  
  181.     if (ioctl(STDIN_FILENO, TCGETA, &term_old) == -1) {    
  182.     perror("get termio1");
  183.     resetfiles();
  184.     exit(1);
  185.     }
  186.  
  187.         /* and get some stats we can change */
  188.  
  189.     if (ioctl(STDIN_FILENO, TCGETA, &term) == -1) {
  190.     perror("get termio2");
  191.     resetfiles();
  192.     exit(1);
  193.     }
  194.     term.c_lflag &= ~ICANON;          /* get the charcters immediately */
  195.     term.c_cc[VMIN] = (char) 0;        /* no char buffered */
  196.     term.c_cc[VTIME] = (char) 0;    /* and no timeout */
  197.  
  198.         /* use our new settings */
  199.  
  200.     if (ioctl(STDIN_FILENO, TCSETA, &term) == -1) {
  201.         perror("set termios");
  202.         resetfiles();
  203.         exit(1);
  204.     }
  205.  
  206.     signal(SIGIO, handler); /* where to go with the signal */
  207.  
  208.     sleep(20);        /* now let's do something (sleep) */
  209.  
  210.     resetfiles();    /* reset all we changed */
  211. }
  212.  
  213. -- 
  214. Klaus M"uller  (mueller@rbg.informatik.th-darmstadt.de)
  215. IRC: netmage       MUD: loren
  216.  
  217. -----------------------------
  218.  
  219. From: Paul Hite <paul@prcrs.prc.com>
  220. Subject: Re: Detecting if running under chroot
  221. Date: 11 Nov 92 16:11:41 GMT
  222. To:       unix-wizards@sem.brl.mil
  223.  
  224. In article <mark.721121538@coombs>, mark@coombs.anu.edu.au (Mark) writes:
  225. > I was reading some of the security texts on research.att.com and it mentioned
  226. > that it was possible to detect if one was running under a chroot call.
  227. > If the file system is duplicated etc how would you check? Make a massive file
  228. > on the (apparent) root disk (/tmp for instance) and do a 'df' to make sure
  229. > it's the root disk?
  230.  
  231. Well I've played around some public access bbs systems that thew me into a
  232. chroot env.  From a practical standpoint, I quickly noticed how little I could
  233. do.  It just had the "feel" of a chroot environment.  But I guess that you're
  234. looking for a more formal method.  I would examine the inode of the root.  I
  235.