[TUHS] Subject:unpipeIt'seasy for a process to insert a new process intoapipelineeither upstream or down unpipe

[TUHS] Subject:unpipeIt'seasy for a process to insert a new process intoapipelineeither upstream or down unpipe

[Doug McIlroy]

It's easy for a process to insert a new process into a
pipeline either upstrean or downstream. Was there ever a 
flavor of Unix  in which a process could excise itselfa
from a pipeline without breaking the pipeline?
Doug

[TUHS] Excise process from a pipe

[Warren Toomey]

On Wed, Jul 09, 2014 at 10:49:22PM -0400, Doug McIlroy wrote:
> It's easy for a process to insert a new process into a
> pipeline either upstream or downstream. Was there ever a 
> flavor of Unix in which a process could excise itself
> from a pipeline without breaking the pipeline?

If in the middle of a pipeline, all I can think of is:

	close fd 0 and fd 1
	dup() read end of pipe 1 to be stdin (fd 0)
	dup() write end of pipe 2 to be stdout (fd 1)
	exec("/bin/cat")

Cheers, Warren

[TUHS] Excise process from a pipe

[Dave Horsfall]

On Thu, 10 Jul 2014, Warren Toomey wrote:

> If in the middle of a pipeline, all I can think of is:
> 
> 	close fd 0 and fd 1

My Unix kernel knowledge is a little rusty (shame on me!), but wouldn't 
that generate pipe errors on both sides i.e. EPIPE and the infamous 
ENOTOBACCO?

-- Dave

[TUHS] Excise process from a pipe

[Christopher Vance]

On Thu, Jul 10, 2014 at 2:52 PM, Warren Toomey <wkt at tuhs.org> wrote:

> On Wed, Jul 09, 2014 at 10:49:22PM -0400, Doug McIlroy wrote:
> > It's easy for a process to insert a new process into a
> > pipeline either upstream or downstream. Was there ever a
> > flavor of Unix in which a process could excise itself
> > from a pipeline without breaking the pipeline?
>
> If in the middle of a pipeline, all I can think of is:
>
>         close fd 0 and fd 1
>         dup() read end of pipe 1 to be stdin (fd 0)
>         dup() write end of pipe 2 to be stdout (fd 1)
>         exec("/bin/cat")
>
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>

Hi, Warren.

That still leaves a process, even if it is a relatively lean one. Besides
your fd 0 is presumably already the read end of the input pipe, and fd 1 is
already the write end of the output pipe. You could probably reduce the
whole thing to the last line.

I don't think Doug's request can be done without some new kernel call (or
other kernelly goodness) to munge file table entries (nomenclature?) for
the process on at least one side (or more likely both) of the self-excisor.
Someone may have done it, since I have heard rumours of some novel hacks,
but it presumably didn't get very far.

Assuming you have pipes on each side, consider what to do with any buffered
data.

-- 
Christopher Vance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140710/e50cda86/attachment.html>

[TUHS] Excise process from a pipe

[Warren Toomey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

>    On Thu, Jul 10, 2014 at 2:52 PM, Warren Toomey <[1]wkt at tuhs.org> wrote:
>      Â  Â  Â  Â  close fd 0 and fd 1
>      Â  Â  Â  Â  dup() read end of pipe 1 to be stdin (fd 0)
>      Â  Â  Â  Â  dup() write end of pipe 2 to be stdout (fd 1)
>      Â  Â  Â  Â  exec("/bin/cat")

On Thu, Jul 10, 2014 at 03:06:11PM +1000, Christopher Vance wrote:
>    Hi, Warren.
>    That still leaves a process, even if it is a relatively lean one.

Hi Chris! Very true.

>    Besides your fd 0 is presumably already the read end of the input pipe,
>    and fd 1 is already the write end of the output pipe. You could
>    probably reduce the whole thing to the last line.

Of course. If the shell set up the pipeline then we only have to exec("cat")
and leave /bin/cat shuffling the data from one pipe-end to the other.

As there are two distinct pipes, each with their own buffers, I can't see
a way of coalescing them into a single pipe without, as Chris suggests,
some kernelly goodness. Indeed, ugliness and complexity kernel-wise!

Cheers, Warren

[TUHS] Excise process from a pipe

[Doug McIlroy]

In the suggested answer, the code changes but the process survives.

[TUHS] Excise process from a pipe

[Doug McIlroy]

In the suggested answer, the code changes but the process survives.

I suspect the answer to my original question is no, but I know only a tiny
fraction of the cumulative API of the extended Unix family.

Doug

>> Was there ever a
>> flavor of Unix in which a process could excise itself
>> from a pipeline without breaking the pipeline?
>
> If in the middle of a pipeline, all I can think of is:
>
>       close fd 0 and fd 1
>       dup() read end of pipe 1 to be stdin (fd 0)
>       dup() write end of pipe 2 to be stdout (fd 1)
>       exec("/bin/cat")

[TUHS] Excise process from a pipe

[Larry McVoy]

I'm pretty aware of the various flavors of Unix and unless the process 
in question is willing to help I can't see how this could work.

There are system calls for passing file descriptors but you have the 
problem that the pipe itself is a buffer of some size and you'd have
the problem of draining it.

Every utility that you put in a pipeline would have to be reworked
to pass file descriptors around, it would be really unpleasant and
not at all Unix like.

On Thu, Jul 10, 2014 at 08:04:43AM -0400, Doug McIlroy wrote:
> In the suggested answer, the code changes but the process survives.
> 
> I suspect the answer to my original question is no, but I know only a tiny
> fraction of the cumulative API of the extended Unix family.
> 
> Doug
> 
> >> Was there ever a
> >> flavor of Unix in which a process could excise itself
> >> from a pipeline without breaking the pipeline?
> >
> > If in the middle of a pipeline, all I can think of is:
> >
> >       close fd 0 and fd 1
> >       dup() read end of pipe 1 to be stdin (fd 0)
> >       dup() write end of pipe 2 to be stdout (fd 1)
> >       exec("/bin/cat")
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm