shell scripts in system commands

[John Esak]

<top-posted for ease of clarity>

Brian,

I did your test below. Aside from needing to actually _have_ as many records
in the file as you want to operate on... "dexpand filename xxx" only
provides the record space in the key file, it does not actually give you
"blank" records on which to stand... so I physically made 10 actual "blank"
records....

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
environment??  I also tried a variety of other tests to get things to fail.
Nothing did. I tried both rreport and dreport. Can't duplicate what you are
seeing with 5.0.14 on SCO Open Server 5.06.

I'm in the room now, should you want to diagnose this a little furhter.

John Esak

Visit The FP Room www.tinyurl.com/yuag7 24/7


> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com
> [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Brian K.
> White
> Sent: Wednesday, November 24, 2004 11:54 PM
> To: filePro mailing list
> Subject: shell scripts in system commands
>
>
> 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
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list