no input files message from printer file

[Barry Wiseman]

Fairlight wrote:
> Simon--er, no...it was Barry Wiseman--said:
>> That message is generated when filepro closes the pipe to lp to direct 
>> print output instead to your file.  I believe if you first issue a 
>> "printer reset", then the "printer file" command, that will prevent the 
>> message.
> 
> I'm still not getting it.  I may not be the OP, but I don't see how any of
> the answers concerning "what has to be done to get lp to stop printing that
> message" have been relevant so far to his problem.  
> 
> FROM the docs:
> 
>      PRINTER FILE "filename"
>                         Send output to file "filename".
> 
> I have used this feature myself on Windows 2003 Server with fP 5.0.14 to
> send output directly to a file, do not pass Go, do not collect $200.  It's
> then handled by PrintWiz to convert to PDF for download.
> 
> Key thing being, it does not even -attempt- to print anywhere but to that
> file, nor should it.  No spoolers, no programs--nothing except the file.
> 
> So far, I'm failing to see where `lp` or any other print spooler should
> even remotely be in play while using PRINTER FILE.  Emphasis: ***FILE***.
> 
> Now, my very salient question is:  Why/How is `lp` getting called -at all-
> from PRINTER FILE?  When we know the answer to that, we'll have a
> reasonable chance of providing a sane solution that works.

 > [snip]

On launch, *report opens a pipe to the default print command as defined 
in fp/lib/config (or as overriden in an environment variable or 
command-line flag).  If that command happens to invoke lp, then lp is 
very much in play, before any processing code has been executed.

If the *report job subsequently executes a PRINTER FILE command, that 
pipe to lp will be closed.  If, in certain OS environments (not 
including Windows 2003 server, apparently), lp wants to complain that a 
pipe has been opened and then closed without any traffic to the pipe 
having occurred, that's rather beyond filepro's control, innit?

As I posted earlier, I've found in many *n*x flavors that PRINTER RESET 
will somehow suppress this behavior.  Scott, have you had a chance to 
try that?  If it works for you, it's probably preferable to throwing 
away lp's stderr which may sometimes convey legitimate error messages.