From: postmaster@starlab.csc.com (SMTP MAILER)
Newsgroups: comp.unix.wizards
Subject: Mail not delivered yet, still trying
Date: 23 Nov 92 22:34:04 GMT


 ----Mail status follows----
Have been unable to send your mail to <DGRAY@STARLAB.CSC.COM>
for one day, will keep trying for another seven days.
At that time your mail will be returned.

 ----Transcript of message follows----
Date: 22 Nov 92 03:24:00 EST
From: UNIX-WIZARDS@BRL.MIL
Subject: UNIX-WIZARDS Digest  V17#002
To: "DGRAY" <DGRAY@STARLAB.CSC.COM>

Return-Path: <unix-wizards-request@sem.brl.mil>
Received: from SEM.BRL.MIL by milo.starlab.csc.com with SMTP ; 
          Sun, 22 Nov 92 03:20:23 EST
Received: from SEM.BRL.MIL by SEM.BRL.MIL id ab25769; 21 Nov 92 7:47 EST
Received: from sem.brl.mil by SEM.BRL.MIL id aa25655; 21 Nov 92 7:29 EST
Date:       Sat, 21 Nov 92 07:29:30 EST
From:       The Moderator (Mike Muuss) <Unix-Wizards-Request@BRL.MIL>
To:         UNIX-WIZARDS@BRL.MIL
Reply-To:   UNIX-WIZARDS@BRL.MIL
Subject:    UNIX-WIZARDS Digest  V17#002

UNIX-WIZARDS Digest          Sat, 21 Nov 1992              V17#002

Today's Topics:
                     Re: Keyboard hit in C programs
                 Re: Detecting if running under chroot
                       Re: The Problem with UNIX
      Re: The Problem with UNIX [Includes ANCIENT Usenet traffic]
                       Re: The Problem with UNIX
       Re: >>TAR file on tape distroyed, are files recoverable?<<
                        SCCS ID Keywords problem
                               Re: RPCGEN
               Re: Any TeX (compilation) Gurus out there?
            Problem with Window to Window commands.... HELP!
                        Closing ends of pipe().
                             TTYDEFS Help!
                 Re: HELP! problem with tar PC <-> SUN
        Verbose errors on demand - was Re: The Problem with UNIX
               RESULT: comp.arch.bus.vmebus passes 227:19
                    Re: Does Linux use segmentation?
                           system call write

-----------------------------------------------------------------

From: walter misar <misar@rbg.informatik.th-darmstadt.de>
Subject: Re: Keyboard hit in C programs
Keywords: Keyboard hit, C programs, UNIX
Date: 10 Nov 92 14:54:17 GMT
To:       unix-wizards@sem.brl.mil

In article <1dms9iINNa6m@agate.berkeley.edu>, bernt@valois (Bernt Skottun) writes:
> 
> I am in the process of adapting a C program from the PC for
> the UNIX environment (for SUN 3 running SUNOS 4.1.1).
> In this program it is essential that
> the user be able to stop certain parts of the program
> (e.g. an inner loop) by hitting the keyboard (any key
> is fine) while as long as the keyboard is not touched the execution
> of the program will continue un-interupted (thus a procedure
> which requires, or expects, the user to type in a key stroke at certain
> intervals will not do). In the DOS environment
> I have been able to do this with the "kbhit()" function.
> My question is: what is the equivalent function in the UNIX
> environment? or how does one go about creating such a function?
> Any suggestions will be very welcome. Thanks a lot.
> Bernt Skottun, bernt@valois.berkeley.edu 
>

Ok, since ^C is an 'any key' you only have to catch the SIGINT you
get if ^C is hit.  

#include <signal.h>
signal(SIGINT,function)

In function() ( prototyped as void function(void) ) the first call should
be signal(SIGINT,function) because the behavior of SIGINT is reset to default
by the signal-handler.

Walter

-----------------------------

From: Klaus Mueller <mueller@rbg.informatik.th-darmstadt.de>
Subject: Re: Keyboard hit in C programs
Keywords: Keyboard hit, C programs, UNIX
Date: 13 Nov 92 16:18:18 GMT
To:       unix-wizards@sem.brl.mil


In article <1dms9iINNa6m@agate.berkeley.edu>, you write:
> 
> I am in the process of adapting a C program from the PC for
> the UNIX environment (for SUN 3 running SUNOS 4.1.1).
> In this program it is essential that
> the user be able to stop certain parts of the program
> (e.g. an inner loop) by hitting the keyboard (any key
> is fine) while as long as the keyboard is not touched the execution
> of the program will continue un-interupted (thus a procedure
> which requires, or expects, the user to type in a key stroke at certain
> intervals will not do). In the DOS environment
> I have been able to do this with the "kbhit()" function.
> My question is: what is the equivalent function in the UNIX
> environment? or how does one go about creating such a function?
> Any suggestions will be very welcome. Thanks a lot.
> Bernt Skottun, bernt@valois.berkeley.edu 
>  

Here is a solution to this problem that not even requires to poll the the
the keyboard. It uses SIGIO to get notified, but the program continues with
the loop after the signalhandler  has returned. So you have to think about 
leaving the loop after execution continues :).

I don't know how portable this is, my system is HP-UX. The relevant man-pages 
are: termio(7) and ioctl(5).


#include <sys/ioctl.h>
#include <unistd.h>
#include <signal.h>
#include <stdio.h>
#include <termio.h>

struct termio term_old;

void resetfiles(void) {		/* resets all terminalstat we have changed */
    int arg;

    arg = 0;
    if (ioctl(STDIN_FILENO, FIOSSAIOSTAT, &arg)==-1) {
        perror("unset async");
        exit(1);
    }
    if (ioctl(STDIN_FILENO, TCSETA, &term_old) == -1) {
        perror("set termios");
        exit(1);
    }
}

void handler(int dummy) {	/* handels the SIGIO */
    printf("got it\n");
    resetfiles();	/* clear what we have done */
    exit(0);
}

int main (void) {
    int arg;
    struct termio term;
    
    arg = getpid();	/* tell the keyboard _we_ want the signal */
    if (ioctl(STDIN_FILENO, FIOSSAIOOWN, &arg)==-1) { 
	perror("set owner");
	resetfiles();
	exit(1);
    }

			/* tell the system we want a _signal_ */

    arg = 1;
    if (ioctl(STDIN_FILENO, FIOSSAIOSTAT, &arg)==-1) {
	perror("set async");
	resetfiles();
	exit(1);
    }

		/* keep the old stats */

    if (ioctl(STDIN_FILENO, TCGETA, &term_old) == -1) {	
	perror("get termio1");
	resetfiles();
	exit(1);
    }

		/* and get some stats we can change */

    if (ioctl(STDIN_FILENO, TCGETA, &term) == -1) {
	perror("get termio2");
	resetfiles();
	exit(1);
    }
    term.c_lflag &= ~ICANON;	  	/* get the charcters immediately */
    term.c_cc[VMIN] = (char) 0;		/* no char buffered */
    term.c_cc[VTIME] = (char) 0;	/* and no timeout */

		/* use our new settings */

    if (ioctl(STDIN_FILENO, TCSETA, &term) == -1) {
        perror("set termios");
        resetfiles();
        exit(1);
    }

    signal(SIGIO, handler); /* where to go with the signal */

    sleep(20);		/* now let's do something (sleep) */

    resetfiles();	/* reset all we changed */
}

-- 
Klaus M"uller  (mueller@rbg.informatik.th-darmstadt.de)
IRC: netmage       MUD: loren

-----------------------------

From: Paul Hite <paul@prcrs.prc.com>
Subject: Re: Detecting if running under chroot
Date: 11 Nov 92 16:11:41 GMT
To:       unix-wizards@sem.brl.mil

In article <mark.721121538@coombs>, mark@coombs.anu.edu.au (Mark) writes:
> 
> I was reading some of the security texts on research.att.com and it mentioned
> that it was possible to detect if one was running under a chroot call.
> 
> If the file system is duplicated etc how would you check? Make a massive file
> on the (apparent) root disk (/tmp for instance) and do a 'df' to make sure
> it's the root disk?

Well I've played around some public access bbs systems that thew me into a
chroot env.  From a practical standpoint, I quickly noticed how little I could
do.  It just had the "feel" of a chroot environment.  But I guess that you're
looking for a more formal method.  I would examine the inode of the root.  I