shell scripts in system commands

[Brian K. White]

----- Original Message ----- 
From: "John Esak" <john at valar.com>
To: "Fplist (E-mail)" <filepro-list at seaslug.org>
Sent: Thursday, November 25, 2004 8:30 AM
Subject: RE: shell scripts in system commands


>> Both versions of the script work exactly as they should with and
>> without the
>> #!/bin/sh as the first line.  Could it be something else in your
>
> Oops! typo.  I was really testing with #!/bin/ksh, so don't think this is
> why it was working on my system. I matched the rest of your testing 
> exactly,
> except for actually _having_ 10 "blank" records instead of 10 "unused"
> records.  Is there any chance this could be why your tests were failing? 
> If
> you did your own test according to the message, how did you get past this?
> The "dexpand filename 10" I mean??

it was 100
and there was another typo in that the final command to run is "rreport tst 
..." not "rreport bkw ..."
and I think I might have just happened to have 2 real records in the test 
file

starting fresh following my own post from scratch, I had to say yes to 
default screen 0 and go into iua and hold the esc key down while 100 records 
gets created

Now, with that test, I can get to 28 working levels, 29 fails
you can see a flicker of the error message  "sh: 132587  memory fault"
then rreport processes continue to nest successfully even though the script 
is failing at that point.

that is: when I hit enter after the 28th level, I do see a new rreport that 
says testing 29 and enter after that flashes the error where the script 
tried to run, and then the screen says testing 30, and so on.

that means nesting in general still works for at least some things besides 
ksh scripts, because I am still doing system "rreport .."
to get each new screen.

rreport continues to nest to exactly 49 levels

and bizarrely, the script does work 1 or 2 more times between 30 and 50
5 times in a row, exactly levels 1-28, 43, and 45 worked.
the 1-28 coming out the same I can see, but the 43 and 45 ??? Bizarre!
when I hit 50 it takes about 55 seconds to exit but it does exit all by 
itself if you wait.
(and no, no BackupEDGE running then)

In another session top shows 840 megs out of the 1gig total free at the 
start, dipping only to around 827 free when I have level 50 sitting there 
waiting while I give top and the system time to react if it's going to.

Also while it's sitting there on 50,
# ps -ef |wc -l
    213

So if i'm running out of something, it's not plain ram or process slots.
Perhaps some other tunable.

Now... I remove the bang line from the script and it works every level up to 
49
since I was only asking for 50, that looks like an off-by-one error in the 
process table but nope, ask for 60 or 75 and still only reach 49. 
interesting.

If I put a different bang line in using sh instead of ksh  "#!/bin/sh"
it also works all the way to 49.

in both of these last two cases (no bang, and sh bang) the process hangs 
after 49 and exits after a long time as if 50 was the end of the job.

I put ksh back in the bang line and asked for 60 this time and only got the 
same results as before. ask for 60, get 1-28, 43, and 45 fully working, the 
rest up to 49 rreport itself working, then hang, waiiiit, exit. (that makes 
6 times, and is also 100% of the time so far)

I say 49, the script only works to 49, but rreport itself makes it to 50, 
since I do get a msgbox that says 50 in it.
or maybe that is really the same 49 as the script... consider, when I see a 
msgbox that says 1
it is not 1 level of nesting, it is 0, that instance of rreport was launched 
manually from a command line.
however when the script says "1 worked" that instance of the script was 
started from inside the 0-level rreport, so the script is nested once. Given 
that, it works out that rreport only nests the same 49 times that the script 
does.

I don't know how this relates to my app though. In the app it might be 
possible for a user to use hot keys that launch runmenus and rclerks etc... 
and stack up a lot of nesting, but I certainly wasn't doing that while 
testing this problem.
I was exactly 1 level in (or 2 however you want to count them), rclerk, runs 
rclerk, runs script. The differences are that the process tables were much 
larger, auto processing was run, it's rclerk instead of rreport, several 
files were potentially open in the form of lookups and a form command that 
printed to a file, which the 2nd rclerk manipulates (print/fax/email...)

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani