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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4495 invoked from network); 22 Feb 2021 03:32:56 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 22 Feb 2021 03:32:56 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2046F9CA78; Mon, 22 Feb 2021 13:32:55 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D4F0493D39; Mon, 22 Feb 2021 13:32:29 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="pVTB9mEq"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 72FAD93D39; Mon, 22 Feb 2021 13:32:25 +1000 (AEST) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by minnie.tuhs.org (Postfix) with ESMTPS id C776893D32 for ; Mon, 22 Feb 2021 13:32:24 +1000 (AEST) Received: by mail-pl1-f181.google.com with SMTP id a24so6871763plm.11 for ; Sun, 21 Feb 2021 19:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Gqrcib5pwcjl/sxR53DSM1/9h28pEK5ArSxntP0fpm8=; b=pVTB9mEqFqKqaBuqKh2v549RsoN2RjdZntcvsfOOf/qbHz0Jkp5iIsu/4CWZPRzUZZ TtAs8XB+WVEEwKxN1cO60byhS6zfd+Yo5kt21FdtQCyngYK2Orx/4GkC5ZfAORq2v6sW OggACeIEVL/t6VM7wKyWXULGqmi+ehrUNAUjiFxj9J2t48n9fiE6kjX5EuDf75W7/xbs 1ma/V0jJFJEK78ZMCfpoeW86RknVUmI3tISB0XXor+wIrVyvADZ5I4Zk0FLoON/LW6dM zBwfgEnk9tKPlxvTU3pSas5PYuzPl/ZmSDDTUpFzqUFGyqL5imznlk4azOEqmJYO1Xxc oumg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Gqrcib5pwcjl/sxR53DSM1/9h28pEK5ArSxntP0fpm8=; b=qml46zdrc060LpVgoE/5UGVxgOk/HqfIKUPN+GE0J1ptP4gSyitG30H5o9KgFJH1WH 0Vf+3FaAJlxepm+q+wPZmUkiQ4rUn0PvuQxY7XM7uX4HskxE2/xyq+KwYcwNki6X3tfY 4AGARhYdnODFfkYvA+IVaxjQdrWmH7l2t4PbS1btX9sH4pAf9onqMk1K/Gs0bCq06OpW /OrEF6TsbUMVdsE+8ESAdFZo3nBFduXlrg5J503AE3TkLanvbI+W/ooaFWipoMNpGlZi +Pu97ip/wtUuCFjrWDC7zarZe6bWWNOlsZIbFZc0WyrcLFinFnXkZVH5QPT21GbODnN0 K1AA== X-Gm-Message-State: AOAM532VtJXhhViQcl61emS3kBZKdrrdHK22wnsi+9AcHEqNhjeRV1YE pzmrW8WyqLrYLF/8epac/1t8OCeLW9E= X-Google-Smtp-Source: ABdhPJz+qHwt1qTO9n7UpByExEmbmFQwBwrvDH/vEBKz6WOjajs9Qo3Xf8y18zjIPqUel3QXHDBNmw== X-Received: by 2002:a17:90a:f2d6:: with SMTP id gt22mr4492026pjb.235.1613964743858; Sun, 21 Feb 2021 19:32:23 -0800 (PST) Received: from localhost.localdomain ([1.129.238.85]) by smtp.gmail.com with ESMTPSA id j15sm6561681pjg.40.2021.02.21.19.32.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 19:32:23 -0800 (PST) Date: Mon, 22 Feb 2021 14:32:19 +1100 From: "G. Branden Robinson" To: tuhs@minnie.tuhs.org Message-ID: <20210222033217.dkqavclp22sa77ln@localhost.localdomain> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dfcmigzb4odwsusz" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Subject: Re: [TUHS] Proliferation of options is great simplification of pipes, really? 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" --dfcmigzb4odwsusz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable At 2021-02-21T20:34:55-0600, Will Senn wrote: > All, >=20 > So, we've been talking low-level design for a while. I thought I would > ask a fundamental question. In days of old, we built small > single-purpose utilities and used pipes to pipeline the data and > transformations. Even back in the day, it seemed that there was > tension to add yet another option to every utility. Today, as I was > marveling at groff's abilities with regard to printing my man pages > directly to my printer in 2021, I read the groff(1) page: >=20 > example here: https://linux.die.net/man/1/groff A more up to date copy is available at the Linux man-pages site. https://man7.org/linux/man-pages/man1/groff.1.html > What struck me (the wrong way) was the second paragraph of the > description: >=20 > The groff program allows to control the whole groff system by command > line options. This is a great simplification in comparison to the > classical case (which uses pipes only). What strikes _me_ about the above is the awful Denglish in it. I fixed this back in 2017 and the correction shipped as part of groff 1.22.4 in December 2018. > Here is the current plethora of options: > groff [-abcegilpstzCEGNRSUVXZ] [-d cs] [-f fam] [-F dir] [-I dir] [-L arg] > [-m name] [-M dir] [-n num] [-o list] [-P arg] [-r cn] [-T dev] [-w name] > [-W name] [file ...] >=20 > Now, I appreciate groff, don't get me wrong, but my sensibilities were > offended by the idea that a kazillion options was in any way simpler > than pipelining single-purpose utilities. What say you? Is this the > perfected logical extension of the unix pioneers' work, or have we > gone horribly off the trail. I'd say it's neither, and reflects (1) the limitations of the Unix filter model, or at least the linear topology of Unix pipelines[1]; and (2) an arbitrary set of rules determined by convention and common practice with respect to sequencing. Consider the first the question of which *roff preprocessor languages should be embeddable in another preprocessor's language. Should you be able to embed equations in tables? What about tables inside equations (not too insane an idea--consider matrix literals)? Nothing in the Unix filter model implies a choice between these decisions, but an ordering decision must be made. V7 Unix tbl(1)'s man page[3] took a moderately strong position on preprocessor ordering based on more practical concerns (I suppose loading on shared systems). When it is used with .I eqn or .I neqn the .I tbl command should be first, to minimize the volume of data passed through pipes. Another factor is ergonomics. As the number of preprocessors expands, the number of potential orderings of a document processing pipeline also grows--combinatorially. Here's the chunk of the groff front-end program that determines the ordering of the pipeline it constructs for the user. // grap, chem, and ideal must come before pic; // tbl must come before eqn const int PRECONV_INDEX =3D 0; const int SOELIM_INDEX =3D PRECONV_INDEX + 1; const int REFER_INDEX =3D SOELIM_INDEX + 1; const int GRAP_INDEX =3D REFER_INDEX + 1; const int CHEM_INDEX =3D GRAP_INDEX + 1; const int IDEAL_INDEX =3D CHEM_INDEX + 1; const int PIC_INDEX =3D IDEAL_INDEX + 1; const int TBL_INDEX =3D PIC_INDEX + 1; const int GRN_INDEX =3D TBL_INDEX + 1; const int EQN_INDEX =3D GRN_INDEX + 1; const int TROFF_INDEX =3D EQN_INDEX + 1; const int POST_INDEX =3D TROFF_INDEX + 1; const int SPOOL_INDEX =3D POST_INDEX + 1; Sure, you could have a piece of paper with the above ordering taped to the wall near your terminal, but why? Isn't it better to have a tool to keep track of these arbitrary complexities instead? groff, as a front-end and pipeline manager, is much smaller than the actual formatter. According to sloccount, it's 1,195 lines to troff's 23,023 (measurements taken on groff Git HEAD, where I spend much of my time). If you need to alter the pipeline or truncate it, to debug an input document or resequence the processing order, you can, and groff supplies the -V flag to help you do so. A traditionalist need never type the groff command if it offends one's sensibilities--it would be a welcome change from people grousing about copyleft. All the pieces of the pipeline are still there and can be directly invoked. For an alternative approach to *roff document interpretation and rendering, albeit in a limited domain, see the mandoc project[4]. It interprets the man(7) and mdoc(7) macro languages, a subset of *roff, and tbl(1)'s mini-language with, as I understand it, a single parser. Regards, Branden [1] Tom Duff noted this a long time ago in his paper presenting the rc shell[2]; see =A79. [2] https://archive.org/details/rc-shell/page/n2/mode/1up [3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=3DV7/usr/man/man1/tbl.1 [4] https://mandoc.bsd.lv/ --dfcmigzb4odwsusz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmAzJbEACgkQ0Z6cfXEm bc6Eww/9FDUf6TUEvfqs/lW9h5/wPI9wMX7iA4bWKn+6/Nk2qpGcuyGcCLZjGFXF QM967zFfaOt0uWiaNrXRSstB1N+bPc3ZbAMdMaXdZTBALx9enZtbN8TxZg8Socdf sMmyhcBJJY2SF3i0y2PZPVOVv8HDNKgEIjZHttPohdt/aD2mYInE68Gqem8YO77H pK6So4zviHLz2UKuKpz5B8UVMS5xaWcc1b5pwJ2qdx8k1Lxx6fN6IvIo4wmuoL1G lpXCZLqSduUUvTLWHq46rJPDt9Wg+PhVPMdGQeCLOLUWrOVuzZW/iMy1GKO9v9q8 84UuuhPFOviEbRWtfzRYAXBvdPzhkzMiln1y9WroIG/eKKJWDALz/HgpWvQGXW0N 5Oks+aMtUNxWAllyuIBS+QHQqUFAX83zvIDiCEmW1rBi+dT25Nl8m+zN0DLY6TKt E+oH5y44l3DG1canZOFR1zSDr5FvR6vtiDho1O6ssVbibq74sAnQuuwy64mDyAlH EjLA+NBB4DM/KzEfP5VVGI+YGHQGUD1L8ofBGq4PdWV77BKiwqcG+HvV687hahrT EaUxiMpjpHtPuecITgJXnR4pD4w+5bOFcBHOKubbHgVmSxqmfcHy/C1OJcKs4mXM ahb85mmO5dQvgn1rjucrr/lrYGTncbAwGHJQ9Mw6W2KwNhDJEXA= =KrfS -----END PGP SIGNATURE----- --dfcmigzb4odwsusz--