kvancamp@ARDEC.arpa (Kenneth Van Camp -FSAC-) (05/12/87)
Is there a way to get a background process into the foreground in System V?
I know about C-shell's 'fg' command, but this won't work because (1) our
Silicon Graphics System V system doesn't support this aspect of the C-shell,
and (2) the process needs to be brought into the foreground after being
created from a different shell (i.e., I need to logout after creating the
background process).
Here's the problem: I have a C program (and all the source code, so
I can consider C solutions as well as shell solutions) that does alot of
number crunching. Typical runs take several hours, and sometimes as long as
a day. Since I can't tie up my terminal during all that time, it naturally
has to be run in the background. At this time I may logout. However,
during the middle of a long run I would like to log back in and
interrogate/modify the run. To do this, I have set up signal interrupts
(available via the normal Kill command) to alert the program that I wish to
interrogate the model. Doing normal printf stuff, I never see the output on
my terminal because the process is background. I need a way to bring it
into the foreground so I can interact with it.
Alternatively, I can just write to the tty device directly. I tried
this, and it worked for output but not for input. Here's an example, which
always reports num=0 and does not wait for user response. I'd appreciate
any suggestions.
/* testbg.c: test writing/reading from background process */
#include <stdio.h>
#include <sys/signal.h>
int useio = 0;
main()
{
FILE *filout, *filin, *fopen();
int (*s16_svc())();
int num;
signal (SIGUSR1, s16_svc);
while(1)
if (useio){
filout = fopen ("/dev/console", "w");
filin = fopen ("/dev/console", "r");
fprintf (filout,"Enter a number:\n");
fscanf (filin, &num);
fprintf (filout,"Read number %d\n", num);
fclose (filout);
fclose (filin);
useio = 0;
}
}
/* s16_svc: signal 16 service routine. Sets the global useio flag the first
* five times it is called; the sixth time it stops the program.
*/
int (*s16_svc (sig))()
int sig;
{
static int count = 0;
if (++count > 5)
exit(0);
/* reset the signal so it works again */
signal (SIGUSR1, s16_svc);
/* set the global flag to use the i/o */
useio = 1;
}
--Ken Van Camp <kvancamp@ARDEC.ARPA>
Army Armament Research Development & Engineering Center
SMCAR-FSA-E Building 329
Dover, NJ 07806-5000
(201)724-3334 (AV)880-3334lm@cottage.WISC.EDU (Larry McVoy) (05/13/87)
In article <7338@brl-adm.ARPA> kvancamp@ARDEC.arpa (Kenneth Van Camp -FSAC-) writes: >during the middle of a long run I would like to log back in and >interrogate/modify the run. To do this, I have set up signal interrupts >(available via the normal Kill command) to alert the program that I wish to >interrogate the model. Doing normal printf stuff, I never see the output on >my terminal because the process is background. I need a way to bring it >into the foreground so I can interact with it. Well, how about this? It's a little coding, but you said that was ok. Set it up so that upon receipt of the signal, your process opens two fifo's (I think you might need to be root to create these). The job will open one for reading, the other for writing. But first close 0 and 1 (stdin & stdout) so that the file descriptors returned are also 0 and 1 when you do the opens. Now write a little program that does the same sort of thing - it opens up the same two fifos. Copy stdin to the write fifo, and everything read comes from the read fifo. This may not be clear enough.... Anyone else want to take a crack at this? I'm guessing that this will work - I haven't tried it... Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy
kdw1@sphinx.uchicago.edu (Keith Waclena) (05/13/87)
In article <3574@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes: > > Set it up so that upon receipt of the signal, your process opens two > fifo's (I think you might need to be root to create these). The job > will open one for reading, the other for writing. But first close > 0 and 1 (stdin & stdout) so that the file descriptors returned are > also 0 and 1 when you do the opens. > No need to be root; fifos are the only case of using mknod where you needn't be the superuser (Well, one of the only cases anyway..). Fifos are probably the most elegant way to handle the problem; here's a simple program I use to create fifos on the fly, from the shell (sorry, no shar..): -------- Cut Here -------- Cut Here -------- Cut Here -------- Cut Here /* * fifo make one or more fifos * Usage: fifo name ... * Creates a fifo for each argument. * requires system V * Keith Waclena, kdw1@sphinx.uchicago.{UUCP,EDU,BITNET} * Use it as you like; sell it if you can! * This has compiled an run successfully on: * Pyramid 90x under OSx (att universe) * AT&T 3B5 under System V 2.0.1 */ #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> char *myself; /* Name of this program */ char usage[] = "file ..."; /* possible proper args */ main(argc, argv) int argc; char **argv; { int i; /* index of fifo names in argv */ myself = argv[0]; /* our name */ if (argc < 2) { fprintf(stderr, "Usage: %s %s\n", myself, usage); exit(1); } for (i = 1; i < argc; i++) /* For each name on the cmd line */ if (mkfifo(argv[i]) == -1) /* Make a fifo */ perror(myself); /* report any error */ exit(0); } /* * mkfifo: path -> int * Side effect: creates a fifo in the file system at path. * Returns -1 on error. */ int mkfifo(path) char *path; { return mknod(path, S_IFIFO | 0666, 0); } -------- Cut Here -------- Cut Here -------- Cut Here -------- Cut Here Simple as that. I use fifos quite a bit, so I keep a couple in my ~/dev directory. Just don't let tar find 'em heh heh.. Keith Keith Waclena BITNET: kdw1@sphinx.uchicago.bitnet University of Chicago UUCP: ...ihnp4!gargoyle!sphinx!kdw1 Graduate Library School Internet: kdw1@sphinx.uchicago.edu 1100 E. 57th Street Chicago, Illinois 60637 #include <disclaimer.h>