Bug in *report with -fp

[Fairlight]

At Tue, Mar 13, 2007 at 01:37:47PM -0400 or thereabouts, 
suspect Bruce Easton was observed uttering:
> 
> 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."

My only complaint was with the -fp, which I honestly didn't even know about
until John Esak viewed my OneGate video where I used -f and had previously
been having to define a blank output format just to use processing.  I
don't care about the no-op-ness of the rest of the flags when -f is used.
Fine, there's a reason for it.

> 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 -something- to do.  It may not have processing to use, but
it's still got an output format, and thus something to do.  With use of
just -fp with a non-existant table, effectively there is -nothing- to do.
It's like calling clerk without a screen; would you find it acceptable for
it to just exit silently without telling you what's up if you omit a screen
name or give it a bogus one?  I wouldn't.  Same with using -f and
formats...if it has no format to use, it lets you know about it.  This is a
case of being invoked for nothing, the very purpose of the -fp flag implies
that we're not dealing with a format, but with processing--and there is
none if the table name is not valid.  Yes, it should give you a heads-up,
or at least (in following with the clerk/screen example) let you choose
from an existing one.  In fact, that's the most semantically compliant
solution across the board, if you consider what happens when you don't
specify a filePro file, an index, a screen, etc.  The exception is actually
reporting an error on -f with no format available rather than letting you
choose.

Personally, I don't care one way or another what happens from here on out.
They can leave it or change it.  The annoyance factor was spending the
better part of 30min figuring out how rreport was screwing me over in the
first place.  Now that I'm aware of it, if I ever see report blow through
something like butter without doing anything that's expected of it, I'll
double-check my -fp argument.  The point was having been bitten in the
first place and having wasted time for something that is -not-, in my
opinion, semantically in line with any of the above cited examples, and
didn't at all give me an indication along the same lines, via error or a
list of choices.

At first I thought it was a bug.  It was explained to me that it's not.
Fine, I accept that and moved on.  A couple people are hopping on late,
past the point where I really stopped caring about it like the day it
was explained to me in the first place.  I can't be held responsible for
the continued debate.  But -I'm- not pushing for changes, and haven't
since the explanation.  I do, however, maintain that in the whole of fP's
design, this result is anomalous compared to other, similar situations.
This is the first place I've seen where something required to actually do
-something- has been just blown past, rather than a choice presented or an
error generated.  That's my only thought on it at this time, and it's an
observational point, not necessarily a point of action.

I'm all for healthy debate, but since I started this, can I just say I
think it's being taken a bit far at this late date?  Even the OP (me)
doesn't give a damn anymore except as a casual observation that it's
seemingly inconsistent.  

And Jay, geez, get to your mail sometime within the month you're actually
responding to it, eh?  :)

mark->
-- 
Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!