Re: [TUHS] First appearance of named pipes

[Grant Taylor via TUHS <tuhs@minnie.tuhs.org>]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On 3/6/20 3:44 PM, Noel Chiappa wrote:
> a pipe is a FIFO.

Hum....

Does that mean that I should be able to replace pipes in my shell 
commands with a collections of FIFOs?  I'm not saying that I would want 
to.  Well, at least not beyond an academic exercise.

> RAND ports just allowed (effectively) a pipe to have a name in the 
> file system.

I've got to admit that this statement, particularly the first two words, 
caused me a lot of trouble.  The first few times I read it I kept 
thinking that RAND ported something from another platform / 
architecture.  I now think it effectively means "(the) port (solution) 
from RAND".  Suffice it to say that many of the emails in this thread 
didn't make sense with my first, seemingly incorrect, understanding, and 
made a LOT more sense with my second, seemingly correct, understanding.

> The implementation of both is pretty straight-forward. A pipe is 
> just a file which has a maximum length, after which the writer is 
> blocked. A port is just a pipe (it uses the pipe code) whose inode 
> appears in the file system.

Intriguing.

It is interesting learning the history of things that I've taken for 
granted for 25 years.

This thread aligns quite well with some external reading that I've done 
trying to learn more about file descriptors and redirection.  TL;DR: 
The redirection symbols (syntax) weren't doing what I thought they were 
doing.  I now believe that they change values of variables used for I/O. 
  Much like DD statements in JCL.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]