Re: fileexist(f)

[<br...@ph...>]

Ethan Merritt wrote:

> Huh?  But that is quite broken.  If you read from that data source,
> even 1 byte, then you have poisoned it for actual plotting.

Not necessarily.  If you do it via <stdio.h> functions, you can still 
use fungetc() to put the djinn back into the bottle.  But the real 
problem is, of course a different one: blocking I/O. If you try to read 
from an existing stream, but there's nothing in it, gnuplot may just sit 
there and wait forever

> Anyhow, my main point is that an   xxx_exists()  routine should be
> exactly parallel to the routine used for actual data input.  

I had given up on following this discussion for a while, because I still 
maintain a rather more serious doubt.  The length at which you guys have 
discussed the vagaries of implementing this features brings me back to 
that issue:

I simply don't believe that either of these functions does something 
that gnuplot has to do, or even *can* do meaningfully.

gnuplot is a plotting program.  It's not a command-line shell, and it's 
not a full-featured script language processor.  Nor, IMHO, should it try 
and become either of those.

What's the point of asking a question like "if fileexists", when there's 
nothing useful that could be done with the answer, that we can't already 
do later on, when a command actually tries to read it?   Why ask if the 
bridge is there before you come to it?  What's the assumption based on 
that this file should exist, but maybe it doesn't?  AFAICS, it's based 
on the fact that somewhere a program is running that is supposed to 
create that file.  So what makes it gnuplot's job to check for this event?

It's not as if gnuplot had thousands of other terribly important things 
to do that it should take care of while some other program sets up that 
file.  So why was gnuplot started or that script loaded, before the 
datafile was ready?  We're not the shell.  We're just another program. 
So if some other program is to create a data file and then gnuplot 
should read that file, the right place to ensure that sequence is in the 
other program, or in the shell.  gnuplot is the wrong place to do this.

Worse yet, existence of a file is rather certainly not even the 
information we actually need about that file in the first place.  We 
need to know whether whichever process is writing that file considers 
itself done with it.  There's *no* way at all we could deduce that from 
looking at the file.  It's not even worth trying.

So to sum it up: I really don't see why we would need these functions. 
And given the apparent complexities of implementing it,  I strongly 
suggest we just drop this plan.  It's getting us nowhere we should be.