Re: fileexist(f)

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Thursday 09 March 2006 09:03 am, Hans-Bernhard Br=C3=B6ker wrote:
>=20
>>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?=20

I have to agree with Hans, too, Petr.  If I understand, the idea is to mo=
nitor if a data file changes, then replot it.  Or is it something else?  =
I guess I'm looking for a bigger context of this.  It just seems like som=
ething better dealt with using a little utility or daemon that monitors t=
he file then simply reissues the gnuplot command through a pipe.

At the same time, I'm wondering why gnuplot should plot something if any =
of its specified input files are not present.  Shouldn't there be an erro=
r? =20

Now, Ethan raised an issue in one of our discussions about some method fo=
r conditionally checking the functionality of gnuplot so that the demos d=
on't fail if something isn't compiled inside gnuplot, rather they are sim=
ply skipped using proper adjustment of, say, all.dem.  If that method exi=
sted, might it be possible to use that kind of thing for checking file ex=
istence of a file?

>=20
>=20
> I am in 100% agreement with you.
> The discussion of Petr's xxx_exist() functions was a spin-off
> that was probably a total waste of time.
>=20
> My preferred method of dealing with this issue is to handle
> missing/empty files cleanly during the plotting process.
> That is relatively straightforward for 2D plotting from ascii
> files, and I have already posted a patch that does so.
>=20
> The code for binary files is a mess, and the 3D code
> is very different from the 2D code.  So far I do not see an
> easy way to modify these code paths to handle missing files.

This seems to be a clear case where any code for checking the existence o=
f a file should be at a higher level than binary/ascii/3D/2D.  Are you sp=
eaking about the options part of binary?  Or at a lower level of input on=
ce the options string has been processed?

> Should I go ahead and apply the patch for 2D code,
> which is after all a major category of use?
>=20
> If inspiration (or code clean-up) strikes for the 3D/binary
> case we can deal with that later.  For the present it would
> remain a known limitation that 2D plots can handle missing
> files cleanly, but 3D plots cannot.

Could it be written generic?  A little routine that can be called by the =
options handling no matter if it is 2D, 3D, ascii or binary?  (We're talk=
ing at the options, level, right?)

I can probably help out with short patches on say, regarding what came up=
 the other day (below), but I'd prefer some unification eventually.

Dan

*****

An alternative might be to move just this chunk of code:

#ifdef HAVE_SYS_STAT_H
       struct stat statbuf;

       if ((stat(df_filename, &statbuf) > -1) &&
           !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
           os_error(name_token, "\"%s\" is not a regular file or pipe",
                    df_filename);
       }
#endif /* HAVE_SYS_STAT_H */

which I think sort of checks the existence of the file without really ope=
ning it.  And replace it with

#ifdef HAVE_SYS_STAT_H
       struct stat statbuf;

       if ((stat(df_filename, &statbuf) > -1) &&
           !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
           os_error(name_token, "\"%s\" is not a regular file or pipe",
                    df_filename);
       }
#else
    if (<open fails>)
        error("Can't open data file "xxx"");
    else
        close_file();
#endif /* HAVE_SYS_STAT_H */

Would that kind of thing work?  That would mean if there is no "stat()" t=
hen the file would be opened and closed for checking existence (also chec=
k for emptiness?), then after options are checked opened again for readin=
g.

Or would you prefer opening and keeping track of the file pointer and doi=
ng a "close" before each instance of "error()"?=20