netnews@wnuxb.UUCP (Heiby) (04/26/85)
Unix Technical Digest Fri, 26 Apr 85 Volume 1 : Issue 47
Today's Topics:
Administrivia
How can you look at the u.area of another process?
I/O redirection to pipes question
proper use of su
using adb with child processes
wanted finer granularity sleep
----------------------------------------------------------------------
Date: Fri, 26 Apr 85 16:30:28 GMT
From: Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP>
Subject: Administrivia
My faith in human nature is restored. I'd like to apologize to all those
who have submitted items for mod.unix (some over a month ago) that have
not seen their submissions show up in a digest. I just discovered a huge
gravity well on my system where all the mail was getting trapped. It is
in the process of being liberated now (80K+). Here is the first of it.
Submissions to cbosgd!unix will find there way to me. Sorry about all this.
Ron.
P.S. Don't forget to put reasonable subject lines on your submissions!
A subject line of "Re: Unix Technical Digest Vol 1 #NN" is even less useful
in a reply/followup as it was in the original digest. Even if the *real*
subject gets put into the message body (1st or 2nd line) I'll probably
find it. Thanks. RWH.
------------------------------
Date: Mon, 1 Apr 85 13:20:14 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: How can you look at the u.area of another process?
Suggest that you look at how the 'ps' program on your system does it.
Essentially, the proc table entry contains a pointer to the address
of the u-area in memory and/or on swap/page space. Which of these it
is determines how you proceed to locate it -- typically, by reading
/dev/mem and /dev/swap (rswap, page, whatever).
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
------------------------------
Date: Wed, 3 Apr 85 23:29:20 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: I/O redirection to pipes question
I'll assume you want to do this in C. [It prob'ly should have been
asked in net.lang.c, but it's been answered there a number of times.]
/* assume 0 = STDIN, 1 = STDOUT */
if (pipe(p1) < 0) quit
if (pipe(p2) < 0) {
cleanup and quit
}
switch (pid = fork()) {
case -1: /* erroror */
scream
cleanup
break
case 0: /* child */
close(p1[0]); /* output */
close(p2[1]); /* input */
dup2(p2[0], 0); /* close(0); dup(p2[0]); becomes 0 */
dup2(p1[1], 1); /* close(1); dup(p1[1]); becomes 1 */
close(p1[1]);
close(p2[1]);
/*
** the above aren't checked 'cuz if one fails, something
** is quite wrong.
*/
exec your program
complain: exec failed.
exit(1);
default: /* parent */
close(p1[1]);
close(p2[0]);
write your stuff to p2[1], read it from p1[0].
when you are done writing to child, close(p2[1])
to give it an EOF.
watch out for deadlock relating to:
parent writes lots to child;
child writes lots to parent, hangs up waiting
for parent to read;
parent writes lots more to child, hangs up
waiting for child to read!
if a read returns 0 the child has died.
if the child has died, a write will give a SIGPIPE:
be careful to allow for this.
while ((wval = wait(&status)) != pid) {
if (wval < 0) {
status = ERROR;
break;
}
}
break
}
Hope you have fun with this code. If you don't understand it, study
it a while, and send me a note saying what you think it does. If you
include a stamped, self-addressed electronic envelope, I'll send back
a canned description of the effects of the above. ;-)
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
------------------------------
Date: Wed, 3 Apr 85 23:40:05 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: proper use of su
> I can do:
> /bin/su news < shell.script
> and sometimes I have to do:
> echo shell.script | /bin/su news
> Could someone explain this? thanks
Really simple, actually. The first wants to read a file named
shell.script. The second wants to read the word "shell.script".
Not the same, or even similar, usage at all. Your example, in
which you use the same program and a word which also happens to
be a file name, is misleading. Here's the distinction:
suppose file "yes" contains the one word "no":
no
then:
% cat < yes
no
% echo yes | cat
yes
%
I'll bet the args to your "echo" are really a command to the shell,
perhaps an executable shell script, while your <'d shell.script
is necessarily a shell script, though not necessarily executable.
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
------------------------------
Date: Tue, 2 Apr 85 13:11:02 est
From: gatech!galbp!root (Ernie Co-vax)
Subject: using adb with child processes
Problem: I would like the ability to follow a parent process up to the
point where it "forks" and "execs" a child and then follow along
in the child process as well.
Question: Is there a version of adb (or something similar) that allows
the simultaneous monitoring of parent and child processes? Any
suggestions as to how to hack adb to accomplish this?
Please respond by E-mail to: {akgua,gatech}!galbp!tab
Thanks!
Tom Bohannon
Computer R&D
{akgua,gatech}!galbp!tab
------------------------------
Date: Wed, 3 Apr 85 22:43:41 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: wanted finer granularity sleep
We did this a long time ago, when we were at SAI. You need a KW11-P
(programmable real-time clock) or equivalent. You need to make sure
that the system does not catch the RTC interrupts at the same place
as the LTC, and then provide your own interrupt routine to just count
ticks. Our RTC was capable of interrupting a million times a second:
obviously, if we'd allowed it to, the system would never have kept up.
The interface can be a limited "millisleep"-type system call, or you
can, if you want, have more interesting control via ioctl's. We opted
for the latter, except in V6+ we still called 'em stty's & gtty's.
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)