below.. in-line On Sat, Mar 7, 2020 at 7:18 AM Paul Ruizendaal <pnr(a)planet.nl> wrote: Steve Glaser hacked was playing with them at Tektronix in 1979, as he had put them into their V6 system before I got there IIRC. I switched the user code to use Chesson's MPX in V7, which is why I think they never were used much in V7. I've forgotten what Bruce used for UNET - I'm CC'ing him here, hoping to jog his memory., Yes, that's right. And if you were someone like Masscomp or Pyramid trying to thread both systems, we had both in our kernels.

Always bemused me that to get a named local I/O connection one ended up with "Unix domain (what does that even mean?) sockets" rather than named pipes, especially since sockets are about as natural a Unix concept as lawn mowers. I've been told, but haven't confirmed, that early sockets didn't even support read and write. They still don't support open and close, and never will. Networks are not intrinsically more special than any other I/O peripheral, but they have become gilded unicorns mounted on rotating hovercrafts compared to the I/O devices Unix supported before them. -rob On Sun, Mar 8, 2020 at 3:48 AM Derek Fawcus <dfawcus+lists-tuhs(a)employees.org> wrote:

On Sun, 8 Mar 2020, Rob Pike wrote: Indeed... They had their own I/O calls such as send()/recv() (and still do). Huh; imagine my surprise when I named a function "shutdown()" because it was called at SIGTERM to clean up... And that's being polite... They are the worst interface that I have ever seen (including OS/360). At a previous $ORKPLACE there was a library that said simply "I am server on port N" and "I want to contact a service on a.b.c.d on port N"; I wish I'd stole^Wborrowed it when we eventually parted company. -- Dave

Hi Larry, There's Plan 9's dial(2) and friends. http://man.cat-v.org/plan_9/2/dial The ctl file of a connection takes commands like ‘hangup’. http://man.cat-v.org/plan_9/3/ip The idea of dial() just doing the right thing lives on with Go's https://golang.org/pkg/net/#pkg-overview -- Cheers, Ralph.

On Sun, Mar 08, 2020 at 01:36:14PM +1100, Rob Pike wrote: Yeah - I always found that a bit weird, having to use socketpair() to get a bidirectional "pipe". Err - granted on the open; but if my memory serves, close() has been supported on them ever since I started using them ('87). Otherwise the normal fork/dup/close/exec pattern for child processes would not work. Now what would have been useful is a way to have distinct fd's for the local read and write end of (e.g.) a TCP socket - such that one direction could be closed w/o closing the other. Or maybe some fcntl() to dup the bidirectional fd in to a pair of unidirectional fds. That way one could dispense with shutdown for closing one direction, making children and fd passed programs socket agnostic. DF

On 3/8/20 9:13 AM, Derek Fawcus wrote: I believe that this can be done, now. At least I've read that it's possible for one end to close (FIN) a TCP connection without the other end also closing. Thus you end up with the one-way data flow that is still ACKed the way that TCP does. -- Grant. . . . unix || die

Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: Absolutely: $ mkfifo the_fifo $ ls -l the_fifo prw-rw-r-- 1 arnold arnold 0 Mar 10 09:28 the_fifo $ echo foo > the_fifo & sleep 1 ; cat the_fifo [1] 3721 foo [1]+ Done echo foo > the_fifo As you stated, not that you'd want to do that, but you can. Arnold

On Tue, 10 Mar 2020, Chet Ramey wrote: So they would still be subject to the same 8-block limit? I haven't delved into the finer points of named pipes as I rarely use them. Related question: are they the same as Unix-domain sockets? Oddly enough I haven't used those much either. -- Dave

On 3/10/20 1:29 AM, arnold(a)skeeve.com wrote: Thank you for your reply Arnold. As I was reading your reply, I realized that I did not fully convey the question that I was still mulling over in my head. (More in a moment.) This thread is one of about three things happening in my life that have to do with pipes, FIFOs, and file descriptors. I managed to articulate the simpler of the questions while reading Noel's email. The larger more onerous question is could I leverage exec to alter where file descriptors 0 (STDIN), 1 (STDOUT), and 2 (STDERR) are set to, including changing 1 to the value of a FIFO, and 0 of a subsequent command to also be the value of the FIFO, thus have pipe like behavior between two commands without using a pipe or redirection as in ">". This has also gotten me to wonder about the possibility of having multiple commands output to a file descriptor; 1 / 2 / other, that is input to a separate command. Sort of the opposite of tee, in a manner of speaking. I'll try to articulate: $ mkfifo test.fifo $ exec 3>&1 $ exec 1> test.fifo $ for l in {a..z}; do echo $l; sleep 1; done & $ for L in {A..Z}; do echo $L; sleep 1; done & $ for n in {1..100}; do echo $n; sleep 1; done & $ exec 1>&3 $ cat test.fifo This seems special to me in that I have three processes (for loops) writing into what is effectively the same pipe. After having mulled this over for a few days and typing this out, I realize that the "pipe" is really just a fifo and that in this case the fifo is a named pipe on the file system. I could do the same thing with a file. Historically I would have done the same thing with a file. But now I realize that the file is not required and that I can use a fifo which is in memory and never hits the disk. (Save for creating the name interface to the pipe / fifo.) At least, I think that's all accurate. I would be very eager to learn from anyone who is willing to teach me pointers. :-) -- Grant. . . . unix || die

Hi Grant. Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: There's nothing preventing you from doing that. After the fork() and before the exec(), just close() and dup() the relevant fds in the right order and you're set. I don't think that this is any different from: (for l in {a..z}; do echo $l; sleep 1; done & for L in {A..Z}; do echo $L; sleep 1; done & for n in {1..100}; do echo $n; sleep 1; done &) | cat which reduces to: (for l in {a..z}; do echo $l; sleep 1; done & for L in {A..Z}; do echo $L; sleep 1; done & for n in {1..100}; do echo $n; sleep 1; done &) > /some/file (You might want to background that whole mess given that the final pipeline will sleep for 100 seconds.) It's not any different than calling `stty -tostop' and then simply backgrounding the three loops at the terminal. Try it! (This is the beauty of the Unix model, an fd is just a data sink, we don't care where it goes.) At the cost of tooting my own horn, I recommend my book "Linux Programming by Example: The Fundamentals", which, despite the "Linux" in the title, covers basic Unix programming, including file descriptor manipulation of the sort under discussion here. HTH, Arnold

On Mon, Mar 23, 2020 at 10:49:43AM +0200, Peter Pentchev wrote: Quite. One point being that one could fork/exec a program with those fd's attached to stdin/stdout and it could operate as a normal filter, w/o having to understand it was using a socket. (i.e. closing stdout [hence triggering a FIN], while still reading from stdin) Plus various other games achievable by replumbing fd's. DF

Hasn't that pretty much worked ever since BSD wrote inetd?

netcat ?

So I fooled around making an HTTP request from bash... (printf 'HEAD / HTTP/1.0\r\nHost: dotat.at\r\n\r\n'; cat 1>&2) \ 0<>/dev/tcp/dotat.at/http 1>&0 And I wondered if it would work with ksh too. It does, but there is weirdness. Bash's <> operator follows POSIX, so in my one-liner the 0 is redundant. https://pubs.opengroup.org/onlinepubs/007908799/xcu/chap2.html#tag_001_007_… However when I look at a ksh man page I find it says https://github.com/att/ast/blob/master/src/cmd/ksh93/sh.1#L3458 <>word Open file word for reading and writing as standard output. I thought POSIX got features like this from ksh so I'm curious that a weird little incompatibilty like this has crept in. (The copy of ksh.1 I have from the CSRG archives lacks <> so I guess that version was ksh88?) Tony. -- f.anthony.n.finch &lt;dot(a)dotat.at&gt; http://dotat.at/ Sole: Northerly 6 or 7 at first in west, otherwise easterly or northeasterly 5 or 6. Moderate or rough, occasionally very rough in west. Showers in west. Good.

I can't find it now, but there's a very short rc script that does a modestly realistic telnet client in Plan 9. But you know, that's not Unix. -rob On Thu, Mar 26, 2020 at 1:39 PM Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote:

On 3/25/20 8:38 PM, Dave Horsfall wrote: Nope. I'll try another way +------------------+ +-------------+ --(TCP)-->+ socket stdout +---+ stdin | | nc | | grep | <--(TCP)--| socket stdin +---+ stdout | +------------------+ +-------------+ This example is back to the functionality that (x)inetd would provide. The idea being that grep* would act on the data that came in the TCP connection and send the matching lines out the same TCP connection. *grep is just a hypothetical example here. ~chuckle~ -- Grant. . . . unix || die

On Thu, Mar 26, 2020 at 01:38:17PM +1100, Dave Horsfall wrote: This can't really be done with netcat, but it's quite easy to do with socat; here's an example with a trivial program that reads lines from its standard input and writes a single line to its standard output: [roam@straylight ~]$ socat -v tcp4:nimbus.fccf.net:25 exec:./heysmtp.py 220 nimbus.fccf.net ESMTP Postfix (Debian/GNU)\r < 2020/03/28 13:09:04.018931 length=6 from=0 to=5 QUIT\r 221 2.0.0 Bye\r [roam@straylight ~]$ All the output was actually from socat because of the "-v" option specified. G'luck, Peter -- Peter Pentchev roam(a){ringlet.net,debian.org,FreeBSD.org} pp(a)storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

Peter Pentchev wrote in &lt;20200328111428.GA1431416(a)straylight.m.ringlet.net&gt;et>: |On Sat, Mar 28, 2020 at 01:12:35PM +0200, Peter Pentchev wrote: |> On Thu, Mar 26, 2020 at 01:38:17PM +1100, Dave Horsfall wrote: |>> On Wed, 25 Mar 2020, Grant Taylor via TUHS wrote: |>> |>>> · netcat's STDOUT to grep's STDIN |>>> · grep's STDOUT to netcat's STDIN |>> |>> Are you trying to set up a loop of processes or something? I'm \ |>> not sure if |>> that is even possible, although you can't rule out creative uses \ |>> of dup2() |>> etc... |> |> This can't really be done with netcat, but it's quite easy to do with |> socat; here's an example with a trivial program that reads lines from |> its standard input and writes a single line to its standard output: |> |> [roam@straylight ~]$ socat -v tcp4:nimbus.fccf.net:25 exec:./heysmtp.\ |> py ... perl(1) has IPC::Open2 for that: use IPC::Open2; # We use `csop' for hashing my $MAILX = 'LC_ALL=C s-nail -#:/'; sub hash_em{ die "hash_em: open: $^E" unless my $pid = open2 *RFD, *WFD, $MAILX; foreach my $e (@ENTS){ print WFD "csop hash32 $e->{name}\n"; my $h = <RFD>; chomp $h; $e->{hash} = $h } print WFD "x\n"; waitpid $pid, 0; } hash_em() |...but, of course, this is still not what Derek was talking about |earlier - there is no separation of the file descriptors connected to |the socket: closing the stdout one would not result in a FIN being sent |along the line. Just wanted to add earlier in the thread that on some systems shutdown(2) equals close(2). At least it was like that on Mac OS X (by then) Snow Leopard. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)