Re: Send end-of-file through a pipe without closing the writing end?

[Greg Wooledge]

On Wed, May 29, 2024 at 05:35:36PM -0400, Zachary Santer wrote:
> This might be a little silly. If I have a process communicating to
> another process in a way that involves EOF happening more than once on
> one side or another of the communication, my strategy would be to do
> so with a single FIFO that gets opened (and closed) for reading and
> writing multiple times.

An actual named pipe, as in mkfifo(1)?  OK.

> Can this instead be accomplished with an FD created by exec {fd}> >(
> command ) or by the coproc keyword?

I don't know coprocs.  I've never used them.  Every time I see any
discussion of them I end up more confused than when I started.

I don't think the process substitution syntax ( >(foo) or <(bar) )
allows you to close and reopen the FD which connects it to your script.
I don't want to say "No, you can't do it," but I don't *think* it's
allowed.

Apart from using a named pipe as you're already doing, the other approach
that comes to mind would be to send both chunks of data in the same
stream, with a delimiter between them.  If they're text, then you can
use NUL as a delimiter.  If they're arbitrary binary data, then this
becomes problematic.

The next approach that comes to mind is very similar, just using a length
prefix instead of a delimiter.  If the first chunk of data is 900 bytes,
then you send 900 (encoded in whatever way makes sense), and then the
raw data.  After that, you can send the second chunk of raw data, either
with or without a length prefix (since EOF will mark its end).