Bug in *report with -fp

[Jay R. Ashworth]

On Tue, Mar 13, 2007 at 01:37:47PM -0400, Bruce Easton wrote:
> > 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?

Because there's a semantically viable reason for wanting to specify a
name of a non-existant file for -y and -z: it permits you to force the
use of no table without having to introduce another command line switch.

And, because there's an operationally viable reason for running an
output format with either processing table overridden.

There is, on the other hand, no sensible reason to say "don't actually
run a format, just run this processing table ... which, oh, doesn't
really exist."

There seems no rational reason to permit that -- and indeed, it's
demonstrably bad: Mark demonstrated it pretty clearly, I thought.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274