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=2.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FROM_SUSPICIOUS_NTLD,PDS_OTHER_BAD_TLD,T_TVD_MIME_EPI autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 4920 invoked from network); 19 Aug 2021 11:54:55 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 19 Aug 2021 11:54:55 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id ea060710 for ; Thu, 19 Aug 2021 06:54:52 -0500 (EST) Received: from tarta.nabijaczleweli.xyz (139-28-40-42.artus.net.pl [139.28.40.42]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 13bc88a4 for ; Thu, 19 Aug 2021 06:54:52 -0500 (EST) Received: from tarta.nabijaczleweli.xyz (unknown [192.168.1.250]) by tarta.nabijaczleweli.xyz (Postfix) with ESMTPSA id 03068360272 for ; Thu, 19 Aug 2021 13:54:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nabijaczleweli.xyz; s=202006; t=1629374089; bh=QRREvi9aPQM8n2qvmwZWHvaw9WGUQeO2GnpwcCH5QvQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=J+h8i91HHxq/9V9DCn7CvTsKMlMohaICCeXeYtrSbOuHK6a9jQ66g9OoSrHzDrXk0 IAiCXDm+3vZ+u/QvlOK5mk5beds1LSyxV/LYkzle/hOGEeEdBE+TfZHrAB1rpzob4E EB20h8PZcqpqsjeEEGvmKars6hnU5LGcIFfjoov2VNY33g6KKH1GH4BbfNYvOYlFrw JZJb8pZgU34nhg1usNQmZnShBR6aw8aoA09wSQ6KH6NDaGcUeYoYkLmcS//y/LzOPn tNQTiC7LtPvcfwVaotkjMfMbFy1BGngGMLXrsgAAEK3mr5k3bDb16Nt3+wrZQMZdpv h9ia/nX0KomSA== Date: Thu, 19 Aug 2021 13:54:47 +0200 From: =?utf-8?B?0L3QsNCx?= To: tech@mandoc.bsd.lv Subject: Re: Should .At 32v rather be [AT&T] UNIX/32V rather than Version 32 AT&T UNIX? Message-ID: <20210819115447.sxizpgfuioltpnuj@tarta.nabijaczleweli.xyz> References: <20210818184652.gp3apndkyoa2m3kc@tarta.nabijaczleweli.xyz> <8F26DC01-86AD-420E-B6E2-658C53B0F5C7@alum.mit.edu> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xr7phy75gnznw6ac" Content-Disposition: inline In-Reply-To: <8F26DC01-86AD-420E-B6E2-658C53B0F5C7@alum.mit.edu> User-Agent: NeoMutt/20210205 --xr7phy75gnznw6ac Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 18, 2021 at 11:34:16PM -0700, Guy Harris wrote: > In what way does calling it "Version 32V AT&T UNIX" bundle it in with V[1= -7]? In the way that "Version 32V AT&T UNIX" is way too close to "Version 7 AT&T UNIX". The latter binds very strongly, because that's the systems most've usually heard about. It's an odd version number to keep that format, because it's so much larger than anything before it, because it's not a version of anything because it's a direct port of V7 to the 32-bit VAX. > (BTW, tsort was in V7, but I digress.) Oh, so it was! I've manged to miss it when I last looked at the dumps somehow. That brings down the utilities that originate from 32V to=E2=80=A6= 0? > However: >=20 > > The designations of early unices originate in their manuals; > > how does 32V stack up here? >=20 > Yes, Bell Labs appeared to call it UNIX/32V, not Version 32V AT&T UNIX. >=20 > However however, if the goal was to be compatible with current versions o= f -mdoc, then calling it Version 32V AT&T UNIX achieves that goal. That ap= pears to date back at least as far as 4.4-Lite-2, from a quick "egrep -i 32= v" in Lite-2's /usr/src/share/tmac directory. I mean, the goal, originally, of anything of this class is to be visually-compatible with established implementations. This I will not disagree with, and it's a good goal. But the end-goal is to be correct, which I believe the current string is not, and I'm inclined to believe that it was a throwaway decision nobody remembers because it also starts with a number, like the other ones. Changing it doesn't have far-reaching layouting compatibility problems, but now that I think about it, AT&T starts with a vowel and Version with a consonant; I'd classify this as "meh". The entirety of NetBSD src/ mentions \b32v\b exactly once: -- >8 -- nabijaczleweli@tarta:~/store/NetBSD/src$ grep -RE '\b32v\b' lib/libc/stdlib/alloca.3:.\" The function appeared in 32v, pwb and pwb.2 an= d in 3bsd 4bsd share/man/man4/man4.vax/dz.4:.At 32v . share/tmac/doc2html:. if "\\$1"32v" Version 32V AT&T UNIX\\$2 share/tmac/doc2html:. if "\\$1"32v" Version 32V AT&T UNIX external/bsd/mdocml/dist/att.c: LINE("32v", "Version\\~32V AT&T UNIX"); external/bsd/mdocml/dist/mdoc.7:.It Cm v[1-7] | 32v external/gpl2/groff/dist/tmac/doc-syms:.ds doc-str-At-32v \&Version\~32V external/gpl2/groff/dist/tmac/doc-syms:.as doc-str-At-32v " \*[doc-Tn-font-= size]AT&T UNIX\*[doc-str-At] external/gpl2/groff/dist/tmac/groff_mdoc.man:.Dl 32v, v1, v2, v3, v4, v5, v= 6, v7, V, V.1, V.2, V.3, V.4 -- >8 -- Illumos does so 0 times. FreeBSD thrice: -- >8 -- nabijaczleweli@tarta:~/uwu/freebsd-src$ git grep '\b32v\b' contrib/mandoc/att.c: LINE("32v", "Version\\~32V AT&T UNIX"); contrib/mandoc/mdoc.7:.It Cm v[1-7] | 32v lib/libc/stdlib/alloca.3:.At 32v . lib/libc/stdlib/alloca.3:.\" The function appeared in 32v, pwb and pwb.2 an= d in 3bsd 4bsd share/man/man7/sticky.7:.At 32v . Binary file sys/contrib/openzfs/tests/zfs-tests/tests/functional/cli_root/z= pool_create/draidcfg.gz matches usr.bin/paste/paste.1:.At 32v . -- >8 -- All of these are roughly "A dz driver appeared in [At 32v].", so I don't think this is a problem. > Presumably, from the Debian bug you filed, your goal is to get all implem= entations of -mdoc changed, not just the mdoc implementation. There are two mdoc implementations in Debian =E2=80=92 groff and mdoc =E2= =80=92 so I could care less about other independent implementations (are there any?). If either of them go through I also plan on posting a similar patch to NetBSD. Illumos and FreeBSD use mandoc in addition to OpenBSD. Am I missing any free system? > (Note, BTW, that calling V7 "Version 7 AT&T UNIX" also dates back to Lite= -2's -mdoc (if not earlier); I'm not sure whether the *operating system* ha= d an official name, or whether it was just the UNIX Programmer's Manual tha= t came with it being the Seventh Edition of the manual.) =2EAt in -mdoc first appeared in 4.4BSD-Alpha as: -- >8 -- =2Ede At =2Enr cF \\n(.f =2Enr cZ \\n(.s =2Eds aa \&\f\\n(cF\s\\n(cZ =2Eif \\n(.$=3D=3D2 \{\ =2E if "\\$1"32v" \&Version 32V \\*(tNAT&T UNIX\\*(aa\\$2 =2E if "\\$1"v6" \&Version 6 \\*(tNAT&T UNIX\\*(aa\\$2 =2E if "\\$1"v7" \&Version 7 \\*(tNAT&T UNIX\\*(aa\\$2 =2E if "\\$1"V" \&\\*(tNAT&T\\*(aa System V \\*(tNUNIX\\*(aa\\$2 =2E if "\\$1"V.1" \&\\*(tNAT&T\\*(aa System V.1 \\*(tNUNIX\\*(aa\\$2 =2E if "\\$1"V.4" \&\\*(tNAT&T\\*(aa System V.4 \\*(tNUNIX\\*(aa\\$2 =2E\} =2Eif \\n(.$=3D=3D1 \{\ =2E if "\\$1"32v" \&Version 32V \\*(tNAT&T UNIX\\*(aa =2E if "\\$1"v6" \&Version 6 \\*(tNAT&T UNIX\\*(aa =2E if "\\$1"v7" \&Version 7 \\*(tNAT&T UNIX\\*(aa =2E if "\\$1"V" \&\\*(tNAT&T\\*(aa System V \\*(tNUNIX\\*(aa =2E if "\\$1"V.1" \&\\*(tNAT&T\\*(aa System V.1 \\*(tNUNIX\\*(aa =2E if "\\$1"V.4" \&\\*(tNAT&T\\*(aa System V.4 \\*(tNUNIX\\*(aa =2E\} =2Eif \\n(.$=3D=3D0 \{\ \&\\*(tNAT&T UNIX\\*(aa =2E\} =2E. -- >8 -- And hasn't changed up to and including 4.4BSD-Lite2. But, no, the research UNIX line didn't have explicit names beyond the manual versions (cf. [1]), but given the manual being distributed with the system, the difference is moot if you consider common usage. Best, =D0=BD=D0=B0=D0=B1 [1]: http://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/Research= /Dennis_v5/v5man.pdf vs http://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/Research/De= nnis_v1/manintro.pdf and http://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/Research/De= nnis_v1/UNIX_ProgrammersManual_Nov71.pdf vs http://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/Research/De= nnis_v2/v2man.pdf --xr7phy75gnznw6ac Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfWlHToQCjFzAxEFjvP0LAY0mWPEFAmEeRoUACgkQvP0LAY0m WPE99Q//XoH24r4VWp4BbtrS8NayrrFBT2srIX52QzKGmlMOg+F1DiNZIa6JzIpc rgUpEt0gaFka2Lph/PxhCtzAzcY2oBT+u7g3c8EYuXB5PYpeEgYN1wBc3U4ENcjC 8+vP0p503LEy/SNduk8KuPx7czbsVe8+o/Cq+f4BPzGZGROyF3Foap9IHmGOn0+U 2hlYQNsRB7RPq5wRu568P0ksYWDKqumJ+L9F7Ce+X3sepGMGlVBa9rJdbqnIQVJg +/YDsK+OL2WANJNJxdtNVXdUgpugopRbrIqcyJI8EPE1rgMSdP5Kg6WgCwoMsTM+ Mnfr+r7zpHuEWKoo88DZKVaOjA3EDI/raJKx5ImRs66SMAKSZ84vGzLAMcGXJN47 AojdGeoFXC/E7RqpXB3jE1zv6FAPLlIFhLqirUdRkfJNHmnIKjcEvBCE7vt3SJfn pM3O3j8KNcxZ0ZcbavZLf6EAK4ASZgOvQ3gLv9xtw0Gm1maE1keh3TEfutUeSZKJ 7nTglHJ9FKULRaYA5QrJCQMrwfPlqBWALO94mba/jx4254zsk0pfL6ElKllyCmz9 gHMNIR46IeiLUK02wY/CxqnpyQ0L2f+yjQwLFMFbhY+BNGvVrpCoCap6xW6Wo7EF +eLzcmlZ6b1ARYrEsfM6RikOXi8GH63gcf9fyIfKZCz4Rd3GfQM= =o/3n -----END PGP SIGNATURE----- --xr7phy75gnznw6ac-- -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv