fpsql documentation

[Brian K. White]

Is there any documentation on fpsql other than the .hlp file?

One of our developers is using fpsql to read filepro data from php.
As far as I can tell the only ways for the user to know how to parse the
fixed length output that fpsql returns is to
A) not set lines 0, and parse the page header lines, and obviously
complicate your collector to deal with the header lines mixed in with
the data.
I have not tried this or even seen what this output looks like, I'm just
reading the .hlp file.
or
B) somehow already know what the field lengths are.

My cohort is currently doing B on a test box by directly reading the map
files also from php.
This requires opening up permissions on many directories and at least
the map files more than I want.

I can think of 2 approaches that are almost good answers. These are the
least broken, most maintainable ideas I can think of, and I don't really
like either one. So I'm hoping that there is something I don't know
about fpsql that answers this need.

The first way is a slightly better version of what the developer is
doing on his own box. Allow apache to read the map files by opening the
directory and map file permissions, but do it as little as necessary
using group permissions.
Make the filepro files all group filepro, and user wwwrun to the filepro
group, and make the filepro file directories 750 and the map files 640.
As long as the keys and indexes are still 600, there really isnt much
sensative data exposed by making the directories and the map files
readable. Maintenance-wise, it just means I would always have to use a
modified fp.list on every one of our boxes for the rest of time.

The other way is have a cron job that periodically rsyncs the map files
to another location with different owner/perms which apache/phpcan read
instead of needing to be able to get into the real filepro tree.

Other ideas? Maybe a sudo or su feature in php that I don't know about?
An suid binary that can read the files would be essentially as bad as
just opening their perms directly, although..., I bet sudo is
configurable enough to do something like that, allow wwwrun to run some
ordinary non-suid binary like cat to read the files, so the perms
wouldn't have to be opened and the binary wouldn't grant anything
special to anyone else. Then again this may introduce a complication and
an inefficiency into the php code that may not be too desirable, having
to run system() or backticks just to grab this field legth data with
every single lookup.

Is there a set lines option or environment variable that means just
output one header like PFONEHEAD for output formats? that would probably
be ideal.

Now that I think about it, if the requesting code issues the set lines
nnn command itself, then it knows when a header is coming, perhaps the
cleanest way is set lines <highest allowed> instead of 0 and just keep a
counter of recieved records and discard the headers when the record
count hits multiple+cumulative_offset of nnn ? The problem there may be
a quirk of the way php imports the records. Maybe it's some single magic
line if the data is homogeneous , but would take more to import line by
line, and then you multiply that difference by every little query you
want to write a a big growing library of ajax routines.

-- 
bkw