shell scripts in system commands

[Brian K. White]

Can anyone with a sco box and a recent version of fp corroborate something 
for me?

The most technically correct way to write a shell script is to specify the 
shell in the first lint that should be used to interpret the rest of the 
script. This makes the script more robust by not relying on hoping that the 
users shell, at the time the script is run, just happens to be the right 
one.

ie:
-----start-----
#!/bin/ksh

echo "This would not work in sh or bash!"
typeset -Z4 n=1
until [ n -gt 3 ] ; do
        echo "$n:\tn\0375=$((n*$n))\trand=$RANDOM"
        n=$((n+1))
done

-----end-----

bash would choke on the ! in the 1st echo
bash nor sh understands typeset -Zn
sh doesn't have built-in math $((...))
bash would need to add -e to the 2nd echo and change \0375 to \375
sh doesn't have $RANDOM

I won't even get into arrays, but ask me how I know to mention them... :)

OK, that off the cuff example is to just head off all the responses that 
amount to "I've never put that at the top before and all my scripts worked 
for the last 16.5 years...". My point is that the syntax is "the right way" 
for a real reason and a script is broken without it and thus anything that 
prevents you from using it is also broken.

My problem is that I'm seeing scripts fail when used inside a filepro system 
command that shouldn't be failing and it's happening on enough boxes that I 
don't think it's anything wrong with a particular box or even a particular 
OS version.
However it's not happening on enough boxes, and not happening to all scripts 
in all places in my fp code that I have to double check that it's not just 
me.

Here is one way to reproduce the problem as far as I can tell:

start a clerk/report process table
in that process table have a system command that runs another clerk/report 
process
in that process table have a system command that runs a shell script
in that shell script have as little as this:

------start------
#!/bin/ksh
echo "hi there, press enter"
read junk
-----end-----


In my case the script fails to run
if I merely take out the hash-bang line the script runs and works

Notice the example script has absolutely no special requirements about 
environment.
It doesn't care if PATH or TERM or any other variables are missing or wrong 
etc...
And in this case, it dosn't include any syntax that wouldn't work the same 
on sh or bash so it doesn't care what shell was used to call it either.

Such scripts had no problem in fp 4.8 and I beleive in early 5.0, I'm still 
testing that out.
5.0.10 and up at least show it.

Don't know about linux or freebsd either and it doesn't apply to windows at 
all.
I can test linux.

All my scripts have that syntax, and they all work perfect when run directly 
or from some other script or any level of parent scripts. I *think* they all 
work when only run from 1 level of parent fp process nesting.
I *think* it's only when fp runs fp runs script, and all via system. That 
is,
rclerk - call table - system script
may work but
rclerk - system rclerk - system script
doesn't


Now, I have some examples that don't fail, and I went so far as to put 
together the following test code that does nothing but nest rreports as far 
as you want by specifying a number with -r nn

And using this 2 levels of nesting work and the 3rd level crashes, which is 
one more level than described above, and more interestingly, it fails at the 
same spot whether the script has the hash-bang line or not.

Yet, it's reproduceable at will in my real app, from any parent rclerk 
process, that a different script, which has nothing but 2 echos and a cat 
command in it, will always fail if the hash-bang is in, and it'll work fine 
if removed.
In the real app it's exactly "rclerk, system rclerk, system script"
and script is just:
----snip----
#!/bin/ksh
echo "\033[7i\c"
cat "$@"
echo "\033[6i\c"
----snip----
it's the passthru-print codes to print to "printer B" out of A, B or C using 
facetwin.
facetwin lets you define 3 passthru printers and you print to them at will 
by sending the normal ansi passthru codes for "printer A" and the above ones 
for "printer B" and esc[9i, esc[8i for "printer C"


Here is the nest-at-will test code:

ddefine tst
filepo, one one-byte field, no screens/output/indexes needed

dexpand tst 100

rcabe tst tst
   If:
Then: msgbox "Testing Level"<@rn<"of"<@pm ; system "/tmp/tst"<@rn
   If: @pm gt "001" and @rn lt @pm
Then: system "rreport tst -fp tst -u -sr"<(@rn+"1")<"-r"<@pm

vi /tmp/tst  , 3 lines:
#!/bin/ksh
echo "Level ${1:-0} works. Press Enter:"
read junk

chmod 755 /tmp/tst

Now run it, asking for 10 levels of nesting via "-r 10"
rreport bkw -fp tst -u -sr 1 -r 10

you can use -r N where N can be up to however many records you have in the 
file, 100 given the above dexpand

You should get both a msgbox and a shell script message for each level of 
nesting.
When you get a msgbox and don't get a corresponding "Level x worked, Press 
Enter:" then the shell script failed.
(or when rreport crashes)

now remove the top line from /tmp/tst
run it again
how many levels of nesting work now?

Thanks

Since the above test fails the same way for me at the same level of nesting 
regardless of the hash-bang, and since the real app really fails at one LESS 
level of nesting, and really works without the hash-bang, and since the real 
script is little more than the nothing script in the test, I no longer have 
much clue what's really wrong or where. So at this point I'm merely asking 
just generally if anyone else has been plagued by things not working from 
system commands that seem like they should work and they do work outside of 
fp?


----
discovered along the way, annoying fp weirdness #767662:
given -r 10,
@pm gt "1" will not test true!
hence the @pm gt "001" above.

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