* Should .At 32v rather be [AT&T] UNIX/32V rather than Version 32 AT&T UNIX? @ 2021-08-18 18:46 наб 2021-08-19 6:34 ` Guy Harris 0 siblings, 1 reply; 6+ messages in thread From: наб @ 2021-08-18 18:46 UTC (permalink / raw) To: tech [-- Attachment #1: Type: text/plain, Size: 1951 bytes --] Hi! At present: -- >8 -- $ printf '.At v7\n\n.At 32v' | ./mandoc -mdoc UNTITLED LOCAL UNTITLED Version 7 AT&T UNIX Version 32V AT&T UNIX -- >8 -- But I believe it should read: -- >8 - $ printf '.At v7\n\n.At 32v' | ./mandoc -mdoc UNTITLED LOCAL UNTITLED Version 7 AT&T UNIX AT&T UNIX/32V -- >8 -- My reasoning being that 32V is a direct port of V7 to the VAX with single-digit and non-formative new utilities (tsort, ..?); bundling it in with V[1234567] is, at its best, disingenuous, and, at worst, just plainly wrong. The designations of early unices originate in their manuals; how does 32V stack up here? /usr/man/man0/title: -- >8 -- Bell Telephone Laboratories, Incorporated Holmdel, New Jersey UNIX/32V PROGRAMMER’S MANUAL Version 1.0 February, 1979 -- >8 -- /usr/man/man0/title] (TM in superscript): -- >8 -- ‐‐ UNIXTM/32V TIME‐SHARING SYSTEM: UNIX PROGRAMMER’S MANUAL Version 1.0, Volume 1 February, 1979 Bell Telephone Laboratories, Incorporated Holmdel, New Jersey -- >8 -- In both cases, the manual is designated as Version 1.0 for "UNIX/32V". The fundamental .At contract is to include "AT&T UNIX", hence why I think "AT&T UNIX/32V" is best. 32V is available for autopsy at http://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/USDL/32V/32v_usr.tar.gz For the record and paralleling major implementations, I've raised this as for groff as Debian #991633: https://bugs.debian.org/991633 The same reasoning is laid out there, no comments at this time. Looking forward to your thoughts! Best, наб [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Should .At 32v rather be [AT&T] UNIX/32V rather than Version 32 AT&T UNIX? 2021-08-18 18:46 Should .At 32v rather be [AT&T] UNIX/32V rather than Version 32 AT&T UNIX? наб @ 2021-08-19 6:34 ` Guy Harris 2021-08-19 11:54 ` наб 0 siblings, 1 reply; 6+ messages in thread From: Guy Harris @ 2021-08-19 6:34 UTC (permalink / raw) To: tech On Aug 18, 2021, at 11:46 AM, наб <nabijaczleweli@nabijaczleweli.xyz> wrote: > My reasoning being that 32V is a direct port of V7 to the VAX > with single-digit and non-formative new utilities (tsort, ..?); > bundling it in with V[1234567] is, at its best, disingenuous, > and, at worst, just plainly wrong. In what way does calling it "Version 32V AT&T UNIX" bundle it in with V[1-7]? (BTW, tsort was in V7, but I digress.) However: > The designations of early unices originate in their manuals; > how does 32V stack up here? Yes, Bell Labs appeared to call it UNIX/32V, not Version 32V AT&T UNIX. However however, if the goal was to be compatible with current versions of -mdoc, then calling it Version 32V AT&T UNIX achieves that goal. That appears to date back at least as far as 4.4-Lite-2, from a quick "egrep -i 32v" in Lite-2's /usr/src/share/tmac directory. Presumably, from the Debian bug you filed, your goal is to get all implementations of -mdoc changed, not just the mdoc implementation. (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* had an official name, or whether it was just the UNIX Programmer's Manual that came with it being the Seventh Edition of the manual.)-- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Should .At 32v rather be [AT&T] UNIX/32V rather than Version 32 AT&T UNIX? 2021-08-19 6:34 ` Guy Harris @ 2021-08-19 11:54 ` наб 2021-08-19 15:13 ` Ingo Schwarze 0 siblings, 1 reply; 6+ messages in thread From: наб @ 2021-08-19 11:54 UTC (permalink / raw) To: tech [-- Attachment #1: Type: text/plain, Size: 5715 bytes --] 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… 0? > However: > > > The designations of early unices originate in their manuals; > > how does 32V stack up here? > > Yes, Bell Labs appeared to call it UNIX/32V, not Version 32V AT&T UNIX. > > However however, if the goal was to be compatible with current versions of -mdoc, then calling it Version 32V AT&T UNIX achieves that goal. That appears to date back at least as far as 4.4-Lite-2, from a quick "egrep -i 32v" 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 and in 3bsd 4bsd share/man/man4/man4.vax/dz.4:.At 32v . share/tmac/doc2html:. if "\\$1"32v" Version 32V <code>AT&T UNIX</code>\\$2 share/tmac/doc2html:. if "\\$1"32v" Version 32V <code>AT&T UNIX</code> 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, v6, 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 and in 3bsd 4bsd share/man/man7/sticky.7:.At 32v . Binary file sys/contrib/openzfs/tests/zfs-tests/tests/functional/cli_root/zpool_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 implementations of -mdoc changed, not just the mdoc implementation. There are two mdoc implementations in Debian ‒ groff and mdoc ‒ 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* had an official name, or whether it was just the UNIX Programmer's Manual that came with it being the Seventh Edition of the manual.) .At in -mdoc first appeared in 4.4BSD-Alpha as: -- >8 -- .de At .nr cF \\n(.f .nr cZ \\n(.s .ds aa \&\f\\n(cF\s\\n(cZ .if \\n(.$==2 \{\ . if "\\$1"32v" \&Version 32V \\*(tNAT&T UNIX\\*(aa\\$2 . if "\\$1"v6" \&Version 6 \\*(tNAT&T UNIX\\*(aa\\$2 . if "\\$1"v7" \&Version 7 \\*(tNAT&T UNIX\\*(aa\\$2 . if "\\$1"V" \&\\*(tNAT&T\\*(aa System V \\*(tNUNIX\\*(aa\\$2 . if "\\$1"V.1" \&\\*(tNAT&T\\*(aa System V.1 \\*(tNUNIX\\*(aa\\$2 . if "\\$1"V.4" \&\\*(tNAT&T\\*(aa System V.4 \\*(tNUNIX\\*(aa\\$2 .\} .if \\n(.$==1 \{\ . if "\\$1"32v" \&Version 32V \\*(tNAT&T UNIX\\*(aa . if "\\$1"v6" \&Version 6 \\*(tNAT&T UNIX\\*(aa . if "\\$1"v7" \&Version 7 \\*(tNAT&T UNIX\\*(aa . if "\\$1"V" \&\\*(tNAT&T\\*(aa System V \\*(tNUNIX\\*(aa . if "\\$1"V.1" \&\\*(tNAT&T\\*(aa System V.1 \\*(tNUNIX\\*(aa . if "\\$1"V.4" \&\\*(tNAT&T\\*(aa System V.4 \\*(tNUNIX\\*(aa .\} .if \\n(.$==0 \{\ \&\\*(tNAT&T UNIX\\*(aa .\} .. -- >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, наб [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/Dennis_v1/manintro.pdf and http://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/Research/Dennis_v1/UNIX_ProgrammersManual_Nov71.pdf vs http://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/Research/Dennis_v2/v2man.pdf [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Should .At 32v rather be [AT&T] UNIX/32V rather than Version 32 AT&T UNIX? 2021-08-19 11:54 ` наб @ 2021-08-19 15:13 ` Ingo Schwarze 2021-09-01 16:53 ` наб 0 siblings, 1 reply; 6+ messages in thread From: Ingo Schwarze @ 2021-08-19 15:13 UTC (permalink / raw) To: nabijaczleweli; +Cc: tech Hello Nab, the string "UNIX/32V" actually makes sense in retrospect because many later operating systems used strings like "systemname/architecture" to distinguish between ports of "systemname" to different architectures. Consequently, i do not object to using this string "UNIX/32V" as part of the output from .At 32v . I do insist, however, that the printed string must contain "AT&T". While UNIX/32V is reasonably well known in general, there may still be people hearing it for the first time and not knowing it came from AT&T. Using "AT&T UNIX/32V" would seem like an improvement to me because it makes clear that "32V" is not a version number. Then again, i think printing "Version 7 AT&T UNIX/32V" might be even better because some people may not know that 32v is just a port of v7, and it is not that much longer. You might worry that the "32V" is easy to overlook in "Version 7 AT&T UNIX/32V". But i would argue that manual pages need to be read attentively in general. Small differences in wording are often crucial, and if a hasty reader misses this particular detail, that's unlikely to have dire consequences. The way to make this change is to open a feature request at https://savannah.gnu.org/bugs/?group=groff unless somebody has already done that, post a message to <groff@gnu.org> mentioning that ticket and briefly summarizing the rationale, ideally also including the patch at the end to ease review. Once that is pushed to the groff git, i will make sure mandoc follows. Nab wrote on Thu, Aug 19, 2021 at 01:54:47PM +0200: > 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 I believe Cynthia Livingston did not usually make "throwaway decisions". > nobody remembers Cynthia added it in this commit: s 00128/00026/00064 d D 5.3 91/04/20 02:36:13 cael 5 3 c register usage changes, reorg .St macro .\" Ns At macro - AT&T UNIX .de At .nr cF \\n(.f .nr cZ \\n(.s .ds aa \&\f\\n(cF\s\\n(cZ .if \\n(.$==2 \{\ . if "\\$1"32v" \&Version 32V \\*(tNAT&T UNIX\\*(aa\\$2 . if "\\$1"v6" \&Version 6 \\*(tNAT&T UNIX\\*(aa\\$2 . if "\\$1"v7" \&Version 7 \\*(tNAT&T UNIX\\*(aa\\$2 . if "\\$1"V" \&\\*(tNAT&T\\*(aa System V \\*(tNUNIX\\*(aa\\$2 . if "\\$1"V.1" \&\\*(tNAT&T\\*(aa System V.1 \\*(tNUNIX\\*(aa\\$2 .\} .if \\n(.$==1 \{\ . if "\\$1"32v" \&Version 32V \\*(tNAT&T UNIX\\*(aa . if "\\$1"v6" \&Version 6 \\*(tNAT&T UNIX\\*(aa . if "\\$1"v7" \&Version 7 \\*(tNAT&T UNIX\\*(aa . if "\\$1"V" \&\\*(tNAT&T\\*(aa System V \\*(tNUNIX\\*(aa . if "\\$1"V.1" \&\\*(tNAT&T\\*(aa System V.1 \\*(tNUNIX\\*(aa .\} .. Did you ask her whether she remembers why she chose these particular words? She is alive for all i know, and was well last time i exchanged mail with her. Then again, maybe this is not really important enough to bother her. If the wording can be improved, it can be changed. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Should .At 32v rather be [AT&T] UNIX/32V rather than Version 32 AT&T UNIX? 2021-08-19 15:13 ` Ingo Schwarze @ 2021-09-01 16:53 ` наб 2021-09-02 12:40 ` Ingo Schwarze 0 siblings, 1 reply; 6+ messages in thread From: наб @ 2021-09-01 16:53 UTC (permalink / raw) To: Ingo Schwarze; +Cc: tech [-- Attachment #1: Type: text/plain, Size: 3573 bytes --] Hi! On Thu, Aug 19, 2021 at 05:13:01PM +0200, Ingo Schwarze wrote: > Using "AT&T UNIX/32V" would seem like an improvement to me because it > makes clear that "32V" is not a version number. > > Then again, i think printing "Version 7 AT&T UNIX/32V" might be even better > because some people may not know that 32v is just a port of v7, and it is > not that much longer. > > You might worry that the "32V" is easy to overlook in "Version 7 > AT&T UNIX/32V". But i would argue that manual pages need to be > read attentively in general. Small differences in wording are often > crucial, and if a hasty reader misses this particular detail, that's > unlikely to have dire consequences. I wouldn't strictly go so far as to say that Version 7 AT&T UNIX/32V is /better/, per se, since the important distinguishing factor is slightly short as compared to the rest of the string and common usage favours implying the Version 7, but then it /is/ at a, quite prominent, end, and is also correct. Either's perfectly fine by me. > The way to make this change is to open a feature request at > https://savannah.gnu.org/bugs/?group=groff > unless somebody has already done that, post a message to <groff@gnu.org> > mentioning that ticket and briefly summarizing the rationale, > ideally also including the patch at the end to ease review. > Once that is pushed to the groff git, i will make sure mandoc follows. Great, thanks for the run-down! > Nab wrote on Thu, Aug 19, 2021 at 01:54:47PM +0200: > > 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 > I believe Cynthia Livingston did not usually make "throwaway decisions". I primarily meant "not giving much thought to something relatively inconsequential". Much like I thought my phrasing was. > > nobody remembers > Cynthia added it in this commit: > > s 00128/00026/00064 > d D 5.3 91/04/20 02:36:13 cael 5 3 > c register usage changes, reorg .St macro > > .\" Ns At macro - AT&T UNIX > .de At > .nr cF \\n(.f > .nr cZ \\n(.s > .ds aa \&\f\\n(cF\s\\n(cZ > .if \\n(.$==2 \{\ > . if "\\$1"32v" \&Version 32V \\*(tNAT&T UNIX\\*(aa\\$2 > . if "\\$1"v6" \&Version 6 \\*(tNAT&T UNIX\\*(aa\\$2 > . if "\\$1"v7" \&Version 7 \\*(tNAT&T UNIX\\*(aa\\$2 > . if "\\$1"V" \&\\*(tNAT&T\\*(aa System V \\*(tNUNIX\\*(aa\\$2 > . if "\\$1"V.1" \&\\*(tNAT&T\\*(aa System V.1 \\*(tNUNIX\\*(aa\\$2 > .\} > .if \\n(.$==1 \{\ > . if "\\$1"32v" \&Version 32V \\*(tNAT&T UNIX\\*(aa > . if "\\$1"v6" \&Version 6 \\*(tNAT&T UNIX\\*(aa > . if "\\$1"v7" \&Version 7 \\*(tNAT&T UNIX\\*(aa > . if "\\$1"V" \&\\*(tNAT&T\\*(aa System V \\*(tNUNIX\\*(aa > . if "\\$1"V.1" \&\\*(tNAT&T\\*(aa System V.1 \\*(tNUNIX\\*(aa > .\} > .. > > Did you ask her whether she remembers why she chose these particular > words? She is alive for all i know, and was well last time i > exchanged mail with her. Then again, maybe this is not really > important enough to bother her. I, uh, haven't, if only because I didn't know the SCCS histories were still available! I had been under the false impression that CSRG CD#3 was The CSRG CD. But, no, I don't believe this is important enough, or that, whatever the reasoning, the final answer to this will change. > If the wording can be improved, it can be changed. > > Yours, > Ingo Oh, and by the by: does your mutt config somehow latinise your mail, or? Best, наб [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Should .At 32v rather be [AT&T] UNIX/32V rather than Version 32 AT&T UNIX? 2021-09-01 16:53 ` наб @ 2021-09-02 12:40 ` Ingo Schwarze 0 siblings, 0 replies; 6+ messages in thread From: Ingo Schwarze @ 2021-09-02 12:40 UTC (permalink / raw) To: nabijaczleweli; +Cc: tech Hi, just to inform the list: Nab now initiated the discussion on the groff side. Nab wrote on Wed, Sep 01, 2021 at 06:53:49PM +0200: > Oh, and by the by: does your mutt config somehow latinise your mail, or? My mutt config is about the longest configuration file i use, which is weird because i dislike config files in general and very strongly prefer minimal ones, but this hasn't anything to do with configuration. I merely prefer sending email using pure US-ASCII and do so manually when there isn't an unusually compelling reason to use UTF-8. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-02 12:40 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-18 18:46 Should .At 32v rather be [AT&T] UNIX/32V rather than Version 32 AT&T UNIX? наб 2021-08-19 6:34 ` Guy Harris 2021-08-19 11:54 ` наб 2021-08-19 15:13 ` Ingo Schwarze 2021-09-01 16:53 ` наб 2021-09-02 12:40 ` Ingo Schwarze
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).