Bug in *report with -fp

[Brian K. White]

----- Original Message ----- 
From: "Fairlight" <fairlite at fairlite.com>
To: <fpsupport at fptech.net>
Cc: "filePro Mailing List" <filepro-list at lists.celestial.com>
Sent: Wednesday, March 07, 2007 8:17 PM
Subject: Bug in *report with -fp


> 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.
>
> Further compounding the confusion was an attempt to use -db with dreport
> and finding nothing wrong, yet having "nothing happen"...mostly because
> there was no processing to debug--which it doesn't warn you about.
>
> Not sure if this has been fixed in 5.6 or not, but anyone using 5.0.14 or
> earlier should beware.

I don't think this is a bug, although a slight enhancement to the way it 
always worked might be nice.

It has always* been the case that input processing and automatic processing 
would run in clerk, and and output processing that matched the form name and 
automatic processing would run in report, unless otherwise told not to.

The only way to say not to was to specify something that doesn't exist.

Thus "-y somethingbogus" can not be considered an error.

-y "" seems like a smarter and obvious "correct" way, and in fact that works 
too, but -y somethingbogus is a lot simpler and more predictable/reliable to 
handle and manipulate than -y "". It can be put into a variable and passed 
as a command line argument to a script and echoed and put in a system 
command etc... and in all those cases somethingbogus will "just work" with 
no risk of getting it wrong whereas you sometimes have to make pretty 
tortured looking code to preserve "".
So myself I've adopted a rule where I use -y NoAuto and I never ever make a 
table named NoAuto
The point is in this case, and the same for -z, this should not be 
considered an error because there is no other more proper way to avoid 
running processing.

As for -fp, well clearly -y, -z, -v, and -fp, are really all just faces of 
the same thing. It may or may not be simple to change -fp without adverseley 
affecting -y and -z (which IMO need to continue working the way they do), 
but even if it is possible, there is at least a weak argument for keeping 
the behaviour of -y -z -v and -fp all the same just for consistency and 
principle of least surprise. Obviously the way it works now surprised you, 
but out of all filepro users would it surprise most of them more if it 
generated an error or if it continued not to? I don't actually offer a guess 
to that, merely pose the question.

The slight enhancement that might be nice is a proper explicit means to say 
"don't run any processing" other than by saying "run this non-existant 
processing"

Then it could be turned into an error if a requested processing didn't 
exist. Except no way can they really do that because of all the code out 
there. So, it would also require YASFEV or YOMAMMA
(yet another special filepro environment variable, or, yet one more annoying 
mode modifying acronym)

(*)well, processing itself in any form didn't _always_ exist, likewise, I'm 
sure the flags to modify processing behaviour werent born the same day as 
processing itself. But I bet the current state of affairs established and 
sorted itself out a long time before Al Gore invented the Internet.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!