Re: fileexist(f)

[Petr M. <mi...@ph...>]

>>    pipeexist(s) which returns 1 for "-" and 1/0 whether it is a pipe
>> wherefrom you can read at least 1 byte;
>
> Huh?  But that is quite broken.  If you read from that data source,
> even 1 byte, then you have poisoned it for actual plotting.

I don't think so. plot '<awk {blalbal} bla.dat' gives always the same.
Can you give an counter-example?

> That's no good.  This is a *pipe*, not a file.  You cannot
> necessarily go back to the beginning and read that byte a
> second time.

I do pclose().


>>>    /*{{{  open file */
>>>    if (*df_filename == '<') {
>>>        if ((data_fp = popen(df_filename + 1, "r")) == (FILE *)
>>> NULL) os_error(name_token, "cannot create pipe for data");
>>
>> This will never work.
>
> ???
> But this is what the code does *now*.
> Are you saying that the current pipe code doesn't work for you?
>
>> The truth is that popen() "never" returns NULL
>> (contrary to specification) -- at least for OS/2, Windows, Linux.
>
> On linux it returns NULL if the pipe open fails.

No, it does NOT! Try it!
popen("bla bla", "r") does not return NULL

>> gnuplot> plot '<bla'
>> sh: bla: command not found
>
> This is the correct error message.
> There is no command "bla", so you cannot pipe its output.

I would prefer no system error message at all.

> On the contrary.  The pipe failed because there is no such command,
> and that is the most enlightening error message.

But did not return NULL. So I must read at least one byte.

> Anyhow, my main point is that an   xxx_exists()  routine should be
> exactly parallel to the routine used for actual data input.  Otherwise
> you cannot trust the result as an indication of whether you will or
> will not be able to plot it.   Thus it should handle both files and
> pipes, because the data input routine handles both files and pipes.

Then I propose   streamexist()  that would do all of that; it would be
equivalent to
 	if (fileexist(file_in_path(x)) || pipeexist(x))

---
PM