[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fflush & close behavior not well-defined

From: arnold
Subject: Re: fflush & close behavior not well-defined
Date: Sun, 13 Sep 2020 23:50:17 -0600
User-agent: Heirloom mailx 12.5 7/5/10


Thanks for the report. Gawk's close already takes an optional second
argument ("from" or "to") for closing one end of a two-way pipe.

If you're willing to hack on the code a bit, I'd have it search the
full list, and upon finding a second instance of the same string,
close it also, but with a warning message.

Otherwise, I think that:

> Or we could just punt and pretend that nobody ever noticed this.

Is the right answer.



"Andrew J. Schorr" <aschorr@telemetry-investments.com> wrote:

> Hi,
> The close and fflush functions take a string argument indicating
> which file or pipe or coprocess to close. But this may not be a
> unique identifier. Consider this silly program:
>       # redirect output to a pipe to the md5sum program in $PATH:
>       print "hello" | "md5sum"
>       # redirect output to a file named md5sum in the current directory:
>       print "junk" > "md5sum"
>       # which file descriptor gets flushed and closed:
>       # the file or the pipe or both?
>       print "flushing and closing"
>       fflush("md5sum")
>       close("md5sum")
>       print "after flush and close"
> }
> By studying the source and using strace, one can learn that only the most
> recently opened file will be the one operated on by fflush or close. So these
> operations are not actually well-defined. 
> One could in theory add an additional optional argument to these functions
> that specifies what type of file is being sought. For example
>    fflush(<filename>, [<filetype>])
> where filetype is one of ">", "|", or "|&". That would match the way
> this information is stored internally in the red_head list in io.c.
> Or we could document that this is nondeterministic. Or we could just
> punt and pretend that nobody ever noticed this.
> Regards,
> Andy

reply via email to

[Prev in Thread] Current Thread [Next in Thread]