From: Daniel J S. <dan...@ie...> - 2006-03-10 00:18:05
|
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 |