Bug in *report with -fp

[Brian K. White]

----- Original Message ----- 
From: "Jay R. Ashworth" <jra at baylink.com>
To: <filepro-list at lists.celestial.com>
Sent: Tuesday, March 13, 2007 2:43 PM
Subject: Re: Bug in *report with -fp


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

Oh come on of course there is. You're nowhere near that obtuse. Must I 
actually spell some examples out?

That process name could be a variable that you may want empty sometimes or 
filled sometimes.
Or you may want filled always but count on the fact that the process 
actually exists sometimes or sometimes not. Either of those could could be 
used to to make slick elegant code where one line just magically works 
several different ways instead of having to code klunky exception cases 
"...but if empty do this instead... or if not empty but table not exist do 
yet another thing instead..."

Whether this is the best way to get that result is a finer point to try and 
make, but you can't say theres no sensible reason for the way it works now. 
It's completely sensible, merely you would preferr it another way.

This is just like the = isn't = argument.

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