Bug in *report with -fp

[Bruce Easton]

My response is inline disagreeing with Jay and somewhat, Ken
-Bruce

> Jay R. Ashworth wrote Monday, March 12, 2007 8:18 PM:
> On Thu, Mar 08, 2007 at 02:42:48PM -0500, fpsupport wrote:
> > 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.
> > [...]
> >
> >[Ken Brody replying . .]
> > 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.)
>
> Fine.  But using -f with a missing *output* format *will* generate
> an error, right?

As Ken says - not a bug and consistent.  Yes missing output format
generates error - so what?  This flag is not referencing a format -
it is referencing a processing table.
>
> > 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.)
>
> Exactly.

Ken - so what if is a "no-op?"  If I run:

~*report myfile -f validformatname -v notthere -y notthere -z notthere -a

from cron, for example, where there is no processing named "notthere,"
or where it was removed, then no error is reported, and no processing
at all is used, which is exactly, for sake of backward compatibility,
what you would expect to happen.  The output, selection and automatic
phases are all "no-op."  The format must exist, but that's a format -
as I stated above the fp flag references only a processing name.

>
> > 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.
>
> Indeed.

Indeed as well - not to the part about "If I were re-designing . .," but
about "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.)
>
> Wheee!  :-)
>

Silly.  Hopefully it is a very low priority and if the change in behavior
is not completely backward compatible, you can count on some screaming
from this end.

Jay also wrote just prior to this:

> I came to this late, but I concur with Mark: the semantics of -fp are
> "force the use of this processing with no output format", and that
> *should* act differently WRT a missing table than -y and -z do; there
> are good reasons to use *those* with names of nonexistent tables (or,
> more properly, the current behaviour allows you to force the non-use of
> such a table without having to have an extra switch for it)...
>
>but that's not sensible given -fp's semantics.
>
>It really ought to complain.

That's your view of the "semantics" of -fp.  Fine.  I see it more as
"don't use any format and what follows is, if it's there [just as other
processing flags would say] the processing to use."

Why would a reason for forming an fp-executable line with an unresolvable
processing name for use with -y, -z, etc. be any better reason than
forming an fp-executable line with an unresolvable PROCESSING name for
use with -fp?

So, I disagree - for backward compatibility's sake (and I mean just back
to the advent of -fp), there should be no complaint from *report.

Bruce

Bruce Easton
STN, Inc.