[TUHS] EOF on pipes?

[TUHS] EOF on pipes?

[Doug McIlroy]

>> pipe, ch(e)root.... Any more unix connections to smoking?

I have a slide that's a quadralingual pun (French, English, Art, shell)
in which Magritte's painting of a pipe with the words "Ceci n'est pas
une pipe" has been altered to read "Ceci n'est pas une |". The
altered phrase was borrowed from Jay Misra et al, who used it as
an example of a message in a paper on communicating processes.

[TUHS] EOF on pipes?

[George Michaelson]

I often wondered about the circumstance which led to | because it felt
like the oddest pipe in the world to me. Its zero pipe units long, its
just an entry and an exit, bolted together. I thought = would have
been much better. I guess there was a good reason that wouldn't fly.

But then I learned there was some clumsy pre-ur-pipe notations which
bolted what > and < do together somehow. I guess if you were there, it
made perfect sense. Confusing as well that | and || both have to
co-exist in the shell, one for IO redirection and process chaining,
and one for expression short circuit operation. So, clearly a lexer is
in the mix, which means maybe == could have worked. Thats a pipe!

I also had long beer filled arguments about how if | was a process,
not just IO bolting, it could be instrumented. Somebody said I should
do that in tee and I did play with that a bit, putting a box on tee to
say what flowed through the pipe. So, maybe the pipe symbol | could
have been modified to be T and then you had a side flow to monitor on.

Designing things is hard. I guess the reality is, you do the bare
minimum neccessary to make it work. Anything else is adding cost.

(I hesitate to say <- and -> might have worked too. few pipes are
bi-directional. Also, the = is being used in ls -lF to denote what
things are non-normal files...)

G

On Sun, Feb 25, 2018 at 1:07 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>>> pipe, ch(e)root.... Any more unix connections to smoking?
>
> I have a slide that's a quadralingual pun (French, English, Art, shell)
> in which Magritte's painting of a pipe with the words "Ceci n'est pas
> une pipe" has been altered to read "Ceci n'est pas une |". The
> altered phrase was borrowed from Jay Misra et al, who used it as
> an example of a message in a paper on communicating processes.
>

[TUHS] EOF on pipes?

[arnold]

George Michaelson <ggm at algebras.org> wrote:

> Designing things is hard. I guess the reality is, you do the bare
> minimum neccessary to make it work. Anything else is adding cost.

Amen!

> (I hesitate to say <- and -> might have worked too. few pipes are
> bi-directional. Also, the = is being used in ls -lF to denote what
> things are non-normal files...)

The = as part of the -F option originates from BSD. It was in 4.2 for sure
(circa 1983); I don't know if it appeared any earlier. But this is
close to 10 years after | was invented for pipes.

Arnold

[TUHS] EOF on pipes?

[Dave Horsfall]

On Tue, 27 Feb 2018, Rudi Blom wrote:

> By using pipe() you create a FIFO pipe with certain limitations 
> (including 5120 write limit). When you open the streams device twice and 
> ioctl() two file descriptors together you have more flexibility.

There's always been a limit on the write until the reader got around to 
it; that's why you had to take care to avoid deadlocks.

Heck, I fell into a deadlock the other day with Perl; I thought that "say 
<$reader_pipe>" (to echo whatever was read) as a neat shortcut would 
work...  It deadlocked, because "<>" was evaluated in list context 
(because of "say") and hence waited for the EOF that would never arrive so 
that I could close the writer end.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] EOF on pipes?

[Rudi Blom]

pipes in SCO UNIX 3.2V4.2,

It's long, long ago, so excuses for vagueness. I think the issue was
not pipe() perse, but the difference in functionality between 'pipe
filesystem' and streams pipes.

By using pipe() you create a FIFO pipe with certain limitations
(including 5120 write limit). When you open the streams device twice
and ioctl() two file descriptors together you have more flexibility.

Excuses for the possible confusion.

[TUHS] EOF on pipes?

[Larry McVoy]

What?!?!  I put networking in some version of SCO, it most certainly 
did have pipes.  Maybe they were faked in the shell but I tend to think
I would have noticed that, I did all sorts of pipelines on that project.

So are you _sure_ the kernel doesn't implement pipes?  SCO would have 
to have taken them out, v7 has usr/sys/sys/pipe.c

On Mon, Feb 26, 2018 at 08:58:02AM -0800, Ian Zimmerman wrote:
> On 2018-02-26 23:03, Rudi Blom wrote:
> 
> > From a piece of code I have in some SCO UNIX 3.2V4.2 source. SCO
> > doesn't have pipes, but you can simulate them.
> 
> Is this a SCO speciality, or are there other UNIXes like that?
> 
> Does it not even have pipe() in its libc?
> 
> -- 
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> To reply privately _only_ on Usenet and on broken lists
> which rewrite From, fetch the TXT record for no-use.mooo.com.

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

[TUHS] EOF on pipes?

[Ian Zimmerman]

On 2018-02-26 23:03, Rudi Blom wrote:

> From a piece of code I have in some SCO UNIX 3.2V4.2 source. SCO
> doesn't have pipes, but you can simulate them.

Is this a SCO speciality, or are there other UNIXes like that?

Does it not even have pipe() in its libc?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[TUHS] EOF on pipes?

[Rudi Blom]

From a piece of code I have in some SCO UNIX 3.2V4.2 source. SCO
doesn't have pipes, but you can simulate them.

	int fd[2]
	int rc;
	struct strfdinsert ins;
	queue_t *pointer = (queue_t *)NULL;

	rc = -1;
	/*
	 * First open the stream clone device "/dev/spx" twice,
	 * obtaining the two file descriptors.
	 */
	if ( (fd[0] = open(SPX_DEVICE, O_RDWR)) < 0)
	{
		gen_trace(gtr_flag, "-gen_pipe(): -open(fd[0]): %s\n", strerror(errno));
		break;
	}
	if ( (fd[1] = open(SPX_DEVICE, O_RDWR)) < 0)
	{
		gen_trace(gtr_flag, ">gen_pipe(): -open(fd[1]): %s\n", strerror(errno));
		close(fd[0]);
		break;
	}

	/*
	 * Now link these two streams together with an
	 * I_FDINSERT ioctl.
	 */
	ins.ctlbuf.buf     = (char *) &pointer; /* no ctl info, just the ptr */
	ins.ctlbuf.maxlen  = sizeof(queue_t *);
	ins.ctlbuf.len     = sizeof(queue_t *);
	ins.databuf.buf    = (char *) 0;        /* no data to send */
	ins.databuf.len    = -1; /* magic: must be -1, not 0, for stream pipe */
	ins.databuf.maxlen = 0;
	ins.fildes = fd[1];     /* the fd to connect with fd[0] */
	ins.flags  = 0;         /* nonpriority message */
	ins.offset = 0;         /* offset of pointer in control buffer */
	if (ioctl(fd[0], I_FDINSERT, (char * ) &ins) < 0)
	{
		gen_trace(gtr_flag, ">gen_pipe(): -ioctl(I_FDINSERT): %s\n", strerror(errno));
		close(fd[0]);
		close(fd[1]);
		break;
	}

[TUHS] EOF on pipes?

[Grant Taylor]

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

On 02/25/2018 03:25 PM, Lyndon Nerenberg wrote:
> And this lived on in the IL network protocol. I've always thought that 
> was one of the more elegant aspects of IL, but of course it didn't have 
> a hope in hell of surviving outside the Plan 9 ecosystem.

"IL network protocol"?  I've never heard of it.

…Quick web search ~> Wikipedia…

Interesting.  #LearnSomethingEveryDay

I really should mess with Plan9 one of these days.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180225/c50d9796/attachment.bin>

[TUHS] EOF on pipes?

[Bakul Shah]

On Sun, 25 Feb 2018 14:25:51 -0800 Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
Lyndon Nerenberg writes:
> > If a stream was marked as using delimeters (and pipes always
> > were), a delimeter was inserted after every write(2).  So
> > write(2) generated an empty message, and read(2) returned it.
> 
> And this lived on in the IL network protocol. I've always thought that was 
> one of the more elegant aspects of IL, but of course it didn't have a hope 
> in hell of surviving outside the Plan 9 ecosystem.

BSD networking has had sequenced packet protocol (SPP) support
pretty much from the beginning (probably due to early XNS
influence).  From socket(2):

     SOCK_SEQPACKET sockets employ the same system calls as SOCK_STREAM
     sockets.  The only difference is that read(2) calls will return only the
     amount of data requested, and any remaining in the arriving packet will
     be discarded.

Even today you can do

    int fd = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);

Presumably read(fd, ptr, 0) works too.

[TUHS] EOF on pipes?

[Lyndon Nerenberg]

> If a stream was marked as using delimeters (and pipes always
> were), a delimeter was inserted after every write(2).  So
> write(2) generated an empty message, and read(2) returned it.

And this lived on in the IL network protocol. I've always thought that was 
one of the more elegant aspects of IL, but of course it didn't have a hope 
in hell of surviving outside the Plan 9 ecosystem.

--lyndon

[TUHS] EOF on pipes?

[Paul Winalski]

On 2/24/18, Norman Wilson <norman at oclsc.org> wrote:
>   Many years ago (when the dinosaurs were using V6), I had a crazy idea[*]
>   that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a
>   subsequent read would wait for further data instead of ENOTOBACCO.
>
>   Did any *nix ever implement that?  I have no idea how it would be done.
>
The pipe device driver that I wrote for VMS implemented EOF.
Mailboxes (the moral equivalent of pipes in VMS) had a WRITE_EOF I/O
command in addition to the usual WRITE.  This placed a special record
in the mailbox's data stream that caused the driver to return
end-of-file when a READ was done instead of simply waiting for further
data.  My pipe driver had to be fully compatible with mailboxes, so it
also had WRITE_EOF.

-Paul W.

[TUHS] EOF on pipes?

[Norman Wilson]

  Many years ago (when the dinosaurs were using V6), I had a crazy idea[*] 
  that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a 
  subsequent read would wait for further data instead of ENOTOBACCO.

  Did any *nix ever implement that?  I have no idea how it would be done.

Have an ENOGORILLA.

To answer the real question: stream pipes, which became the only
sort of pipe in the Research stream (sic) sometime between the
8/e and 9/e manuals.

The implementation was trivial, because from the beginning the
metadata within a stream admitted delimiters: markers that meant
`when this object reaches read(2) at the head end, return from
read with whatever has already been delivered.'  Empty messages
(two consecutive delimiters) were explicitly allowed.

If a stream was marked as using delimeters (and pipes always
were), a delimeter was inserted after every write(2).  So
write(2) generated an empty message, and read(2) returned it.

Norman Wilson
Toronto ON

[TUHS] EOF on pipes?

[Jon Steinhart]

Bakul Shah writes:
> 
> pipe, ch(e)root.... Any more unix connections to smoking?

Well, I don't have any more smoking connections but since we're so off topic,
an old Laugh-In gag always pops into my head when I'm thinking about networking.
It make be a communications endpoint to you but it's a socket to me.

Jon

[TUHS] EOF on pipes?

[Nelson H. F. Beebe]

>> pipe, ch(e)root.... Any more unix connections to smoking?

How about ash, one of the Bourne-family shells?

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[TUHS] EOF on pipes?

[Bakul Shah]

On Sat, 24 Feb 2018 18:13:02 -0500 "Ron Natalie" <ron at ronnatalie.com> wrote:
Ron Natalie writes:
> Unix pipes are not allowed in non-smoking areas.
> 
> -----Original Message-----
>  
> 
> Many years ago (when the dinosaurs were using V6), I had a crazy idea[*]
> that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a
> subsequent read would wait for further data instead of ENOTOBACCO.

pipe, ch(e)root.... Any more unix connections to smoking?

[TUHS] EOF on pipes?

[Ron Natalie]

Unix pipes are not allowed in non-smoking areas.

-----Original Message-----
 

Many years ago (when the dinosaurs were using V6), I had a crazy idea[*]
that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a
subsequent read would wait for further data instead of ENOTOBACCO.

[TUHS] EOF on pipes?

[Dave Horsfall]

Many years ago (when the dinosaurs were using V6), I had a crazy idea[*] 
that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a 
subsequent read would wait for further data instead of ENOTOBACCO.

Did any *nix ever implement that?  I have no idea how it would be done.

[*]

I was full of crazy ideas then, such as extending stty() to an arbitrary 
device and was told by the anti-CSU mob that it was a stupid idea...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."