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

[alex xmb sw ratchev]

using maybe socat tool , it has partly opts to continue when eof recieved

On Thu, May 30, 2024, 12:16 AM Greg Wooledge <greg@wooledge.org> wrote:

> 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).
>
>