katel@amdcad.AMD.COM (Kate Lowenstein) (05/18/88)
Has anyone written a shell script to run the Fortran FCVS interactive test of PAUSE and STOP (test FM257). I am attempting to write a Bourne shell script to provide the answers required by the test, instead of having to type in 'go' five times myself -- my philosophy is to make the computer do the work, not me. However, I have so far been unsuccessful in my attempt. It seems that the system reacts different when the binary is run directly or from a script. I I am trying to use a here document to provide the 'go's but the binary seems to ignore it and instead wants me to type in a 'kill -15 xxxxx'. I'm sure this is a problem with the interaction between Fortran and UNIX, but I keep thinking there must be a way to do this, but so far, I seem to be hitting my head on a brick wall. Any ideas will be appreciated. I have posted this question (slightly differently worded) to comp.unix.wizards, and have tried all their suggestions that were posted to me. Nothing has worked. Thanks very much, Kate
tom@iconsys.UUCP (Tom Kimpton) (05/18/88)
In article <21661@amdcad.AMD.COM> katel@amdcad.AMD.COM (Kate Lowenstein) writes: >Has anyone written a shell script to run the Fortran FCVS interactive >test of PAUSE and STOP (test FM257). > >I am attempting to write a Bourne shell script to provide the answers >required by the test, instead of having to type in 'go' five times >myself -- my philosophy is to make the computer do the work, not me. >However, I have so far been unsuccessful in my attempt. It seems >that the system reacts different when the binary is run directly or >from a script. I suspect that the I/O routines are opening up "/dev/tty" rather than the tty line for that terminal (I don't know for sure), or are checking the type of the input for "ttyness". So... try something like the following: main(argc,argv,envp) int argc; char **argv,**envp; { ... parent = fork() if(parent == 0){ exec("fortprog",argv,envp); } else{ fd = open("/dev/tty",O_WRONLY); /* try fd = 0, if this doesn't work, i.e. testing input * for "ttyness" */ fd1 = open("script",O_RDONLY); /* script is your input script */ while(read(fd1,&c,1) > 0) ioctl(fd,TIOCSTI,&c); /* simulate terminal input */ } } This is probably more than you wanted to do but... I hope this helps! -- Tom Kimpton UUCP: {ihnp4,uunet,caeco,nrc-ut}!iconsys!ron Software Development Engineer ARPANET: icon%byuadam.bitnet@cunyvm.cuny.edu Icon International, Inc. BITNET: icon%byuadam.bitnet (multi-user acct) Orem, Utah 84058 PHONE: (801) 225-6888
sunil@hpcllmv.HP.COM (Sunil Bhargava) (05/19/88)
The PAUSE reacts differently when run in foreground or background. I don't
fully understand your problem but the above may be something to consider.
The way the library probably determines whether the job is in foreground or
background is by using 'isatty'. You may look at 'isatty' in the Unix
documentation to provide you clues that may help identify the cause of your
problem.
A shot in the dark, but hope it helps.
katel@amdcad.AMD.COM (Kate Lowenstein) (05/20/88)
Many thanks to all who sent suggestions. I tried just about every suggested solution. The answer came from Avi Block from National Semiconductor in Israel. Here is his solution: ***************************************************************** ***************************************************************** First of all the reason this happens is because the PAUSE routine checks if stdin is a tty or not. If so, it asks for a GO else it gives the kill message. The idea is to try to find the process number and to send the kill with the found number. The following shell script was what worked: ----------------------------------------------------------------- #!/bin/sh <prog_name> & pn=`ps | grep <prog_name> | grep -v grep | sed 's/ *\([0-9]*\).*/\1/'` kill -15 $pn kill -15 $pn kill -15 $pn kill -15 $pn kill -15 $pn ------------------------------------------------------------------- ***************************************************************** ***************************************************************** again, many thanks to all of you who came through with your suggestions (and thanks, Avi!)