From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FAKE_REPLY_B,MAILING_LIST_MULTI autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 24946 invoked from network); 1 Oct 2021 12:12:04 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2021 12:12:04 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 1EBFD9CBA3; Fri, 1 Oct 2021 22:12:01 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 23E229CB95; Fri, 1 Oct 2021 22:11:37 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="k33f20UH"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 50BD89CB95; Fri, 1 Oct 2021 22:11:35 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.168]) by minnie.tuhs.org (Postfix) with ESMTPS id 2B05F9CB92 for ; Fri, 1 Oct 2021 22:11:30 +1000 (AEST) X-KPN-MessageId: acd5abef-22b0-11ec-8862-005056aba152 Received: from smtp.kpnmail.nl (unknown [10.31.155.40]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id acd5abef-22b0-11ec-8862-005056aba152; Fri, 01 Oct 2021 14:11:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:date:message-id:subject:mime-version:content-type:from; bh=uETI6dpUmzFLixxazIhdUdcYMbH77V9Gwfkh9q1oT10=; b=k33f20UHZ5YVu7Pz8pOhXM8PwPzr2iruxoGbOkHhPvLdXEvJlAP3wrD/wHyNeejw0o3gHoPHOCd/C FxlRy7pLQc7J+JMjEMzxJsgzNYoSUQoSV9uwTUSFTGxK7QqfB8c9Q/ptge8vZUkDbX2BUJdS2Q3a2+ OWLkMrNX7VZBjoBs= X-KPN-MID: 33|gVtWoKsxAVoGbVOGHSfvWWB7WyikzHnFk8kQYjCmUyYI0KMDq1hDPKRqiy0GB3o ox9qvLayLY0ngkRUwzA4xhAWDORacmgf57n4PqWo0oOQ= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|k3DXLVpKGlZeH7I5/Z/S0BZdrJl3Af+hQ2JCAAmVUWQHAn29ZZxOyPtymMZ4HFU aQbrWqERhNRv4CvHu8FsQ0w== X-Originating-IP: 80.101.112.122 Received: from mba2.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id acda12a4-22b0-11ec-b76f-005056ab7584; Fri, 01 Oct 2021 14:11:15 +0200 (CEST) From: Paul Ruizendaal Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Fri, 1 Oct 2021 14:11:14 +0200 To: TUHS main list X-Mailer: Apple Mail (2.3608.120.23.2.4) Subject: Re: [TUHS] Systematic approach to command-line interfaces X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Greg wrote: > I guess pipe(2) kind of started this mess, [...] Maybe I'm > going to far with thinking pipe() could/should have just been a = library > call that used open(2) internally, perhaps connecting the descriptors = by > opening some kind of "cloning" device in the filesystem. At times I=E2=80=99ve been pondering this as well. All of = creat/open/pipe could have been rolled into just open(). It is not clear = to me why this synthesis did not happen around the time of 7th edition; = although it seems the creat/open merger happened in BSD around that = time. As to pipe(), the very first implementation returned just a single fd = where writes echoed to reads. It was backed by a single disk buffer, so = could only hold ~500 bytes, which was probably not enough in practice. = Then it was reimplemented using an anonymous file as backing store and = got the modern two fd system call. The latter probably arose as a = convenient hack to store the two file pointers needed. It would have been possible to implement the anonymous file solution = still using a single fd, and storing the second file pointer in the = inode. Maybe this felt as a worse hack at the time (the conceptual split = in vnode / inode was still a decade into the future.) With a single fd, it would also have been possible to have a cloning = device for pipe=E2=80=99s as you suggest (e.g. /dev/pipe, somewhat = analogous to the implementation of /dev/stdin in 10th edition). = Arguably, in total code/data size this would not have been much = different from pipe(). My guess is that from a 1975 perspective, creat/open/pipe was not = perceived as something that needed fixing.