Bug in *report with -fp

[fpsupport]

Quoting Fairlight (Wed, 7 Mar 2007 20:17:17 -0500):

> There's a bug in dreport and rreport as late as 5.0.14R4 (Linux in this
> case).
>
> If you specify "-fp tablename" on the command line, and the table does
> not exist, it does not complain in any way, shape, or form.  It acts as
> if it just did a sane job of running.
[...]

First, let me say that I do not consider this a "bug", as the behavior
is consistent with the rest of the prc-related flags.  (And using the
"-f" flag for a prc-only output format for which there is no
corresponding processing will generate no error, either.)

That said, however, I do see the value in changing this particular
behavior to one that makes more sense.  That is, since the "-fp" flag
with a non-existent processing name is basically treated as "run this
prc-only output that has no prc, so the entire output phase is
basically a no-op".  (Yes, the sort/select processing [if any] was
run on the first pass, and the automatic processing [if any] will be
run on the second pass.)

If I were re-designing filePro from scratch, I would not have allowed
the non-existent prc name give to the -v/-y/-z flags to be treated as
a "use no processing" flag, unless the name were "" to explicitly set
that meaning.  However, that design decision was made more than 23
years ago, and too many people use too many variants on the name they
give in order to change that behavior.

Changing this behavior for "-fp" has been entered as a requested change
for a future update.  (Task list item number 1000.)

--
Kenneth Brody