Quoth Jan Stary: >On Mar 12 11:56:39, humm@ljabl.com wrote: >> Consider: >> >> .Pq asdf . >> .Pq asdf "." >> >> The expected output: >> >> (asdf). (asdf). > >If I'm reading mdoc(7) right, this is what the >Delimiters section has to say on that: > > When a macro argument consists of one single input character > considered as a delimiter, the argument gets special handling. > This does not apply when delimiters appear in arguments > containing more than one character. > >Your "." (quotes included) contains more than one character, >so it is not a delimiter. In the troff language, a macro does not see the quotes surrounding an argument. An argument can be quoted to contain spaces or quotes; that’s transparent to the macro. So here, the argument does contain a single character and troff -mdoc treats it that way. (Tested 4.4BSD-Lite2’s -mdoc, OpenBSD’s /usr/share/tmac/doc.tmac, and groff -mdoc.) Further, even if that was not the case, the output would still be wrong: .Pq asdf \&. .Pq asdf "." results in (asdf .) (asdf.) >Also, why would you ever do this? You wouldn’t. And yet I did find it in the wild. -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
My smtpd complained that mandoc.bsd.lv does not accept smtp+tls Mar 16 08:38:12 www smtpd[88702]: fb4b78355f0ad3b2 mta connecting address=smtp+tls://66.111.2.12:25 host=bsd.lv Mar 16 08:38:12 www smtpd[88702]: fb4b78355f0ad3b2 mta connected Mar 16 08:38:13 www smtpd[88702]: fb4b78355f0ad3b2 mta error reason=TLS required but not supported by remote host Mar 16 08:38:13 www smtpd[88702]: smtp-out: Disabling route [] <-> 66.111.2.12 (bsd.lv) for 15s Mar 16 08:38:14 www smtpd[88702]: smtp-out: No valid route for [connector:[]->[relay:mandoc.bsd.lv,smtp+tls,pki_name=stare.cz,heloname=mx.stare.cz],0x0] Mar 16 08:38:23 www smtpd[88702]: 0000000000000000 mta delivery evpid=92ce03bda3dffe8e from=<hans@stare.cz> to=<discuss@mandoc.bsd.lv> rcpt=<-> source="-" relay="mandoc.bsd.lv" delay=3d18h17m22s result="TempFail" stat="Network error on destination MXs" so I turned it off to be able to send it. Just FYI, in case you want to TLS on mail.mandoc.bsd.lv (Not to be confused with bsd.lv's mail, handled by google.) Jan -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
On Mar 12 11:56:39, humm@ljabl.com wrote: > Consider: > > .Pq asdf . > .Pq asdf "." > > The expected output: > > (asdf). (asdf). If I'm reading mdoc(7) right, this is what the Delimiters section has to say on that: When a macro argument consists of one single input character considered as a delimiter, the argument gets special handling. This does not apply when delimiters appear in arguments containing more than one character. Your "." (quotes included) contains more than one character, so it is not a delimiter. Also, why would you ever do this? Jan > Mandoc’s output: > > (asdf). (asdf.) > -- > To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv > > -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Consider: .Pq asdf . .Pq asdf "." The expected output: (asdf). (asdf). Mandoc’s output: (asdf). (asdf.) -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Jan: > Apparently one needs to read up on "Using the Feedback Assistant app" > https://developer.apple.com/bug-reporting/#feedback-assistant > and I for one cannot drag myself to anything like that. The thing about the Feedback Assistant is that you don't get to share feedbacks using a link and have others comment on it like a Bugzilla or even Microsoft's Feedback Hub. And usually you don't get any feedback from Apple about what they are doing with it, so it's overall designed to... make you not want to do it. > Interestingly, mandoc is not among the repos at > https://opensource.apple.com/releases/ Yep, GitHub search (see below) turns up nothing. This leads to a tangential complaint with mandoc: there's no version output! The people at GitHub was a little frustrated with that. (PR was stuck for some unrelated reason.)[2] [2]: https://github.com/github/markup/pull/1196#issuecomment-716567772 Ingo: >If something is broken in mandoc, that's more likely to generate >wrong output than to issue an error or warning message. Or it might just get stuck. The test really doesn't make sense: a timeout would work better than a lint. > Do they patch their manuals > when they are broken, or do they merely (every few decades) > pull in complete software packages from FreeBSD and other third > parties, without any local modifications? I have no idea. The BSD manuals seem to match what they are pulling with some edits to match what they do on their own end. And then there's their own manuals for what they write. You can often tell which is which from the quality of the HISTORY section :) They have in at least one case modified a manual page to fix lint errors: https://github.com/apple-oss-distributions/awk/blob/f51027cfca6efef532f95b0b5bcbee995c3e6498/awk.plist#L24. There seems to be a couple more in https://github.com/search?q=org%253Aapple-oss-distributions+mandoc&type=code. Regards, Mingye -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Hi zplus, > -------- Forwarded Message -------- > Subject: mandoc debian release > Date: Sun, 04 Jun 2023 18:23:58 +0200 > From: zPlus <zplus@peers.community> > To: kristaps@bsd.lv > > Hello Kristaps, > there seems to be a problem with mandoc when converting this page[1] > [1] stress-ng.1.en: https://paste.centos.org/view/raw/86b12296 I suspect this to be exactly the same bug as discussed here: https://bugzilla.suse.com/show_bug.cgi?id=1209830 > which I got > from Debian. Basically, halfway through it gets stuck in an infinite > loop, no > error, 100% CPU, just keeps spinning. I used the most recent version, > 1.14.6, > which I found un Debian testing and unstable. > I asked for help on IRC in #openbsd and they confirmed this is fixed in > "yesterday's -current" version. > They pointed me to your website, and suggested that I write to you > asking for a > new release. So this is the reason of my email, could you please make a new > release of mandoc such that Debian can pick up the new changes too? > Thank you a lot! Eventually, we will certainly roll a new mandoc release, but i can't give a time estimate yet when that will happen. In the meantime, if you want to fix the Debian port, can you simply include this patch: https://cvsweb.openbsd.org/src/usr.bin/mandoc/out.c.diff?r1=1.54&r2=1.55 into the Debian port here: https://salsa.debian.org/debian/mdocml/-/tree/master/debian/patches Does that work for you, as a stopgap measure? Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Not sure if this is on the mandoc lists... -------- Forwarded Message -------- Subject: mandoc debian release Date: Sun, 04 Jun 2023 18:23:58 +0200 From: zPlus <zplus@peers.community> To: kristaps@bsd.lv Hello Kristaps, there seems to be a problem with mandoc when converting this page[1] which I got from Debian. Basically, halfway through it gets stuck in an infinite loop, no error, 100% CPU, just keeps spinning. I used the most recent version, 1.14.6, which I found un Debian testing and unstable. I asked for help on IRC in #openbsd and they confirmed this is fixed in "yesterday's -current" version. They pointed me to your website, and suggested that I write to you asking for a new release. So this is the reason of my email, could you please make a new release of mandoc such that Debian can pick up the new changes too? Thank you a lot! [1] stress-ng.1.en: https://paste.centos.org/view/raw/86b12296 -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Hi Ingo, > >> From Apple's open source releases page, it appears that in macOS 13.0 > >> (released last October), their man(1) implementation was replaced with > >> a shell script that calls mandoc. > > > $ mandoc -Tlint /usr/share/man/man*/* > /tmp/lint > > $ wc -l /tmp/lint > > 98362 /tmp/lint > > > > Attached in case Ingo wants to have a look. > > Not quite sure what i'm supposed to do with that output... I didn't mean to say that you are supposed to do anyting - just in case you wanted to have a rough picture of how mandoc handles macOS's manpages, in the spirit of your old slides on trying mandoc on other OSes. > $ sed 's/^mandoc: [^ ]* //' lint | cut -d: -f1-2 | sort | uniq -c | sort -nr > > 53308 STYLE: input text line longer than 80 bytes > 9893 STYLE: whitespace at end of input line > 5629 ERROR: skipping bad character > 5452 WARNING: skipping paragraph macro > 4800 WARNING: empty block > 4675 WARNING: new sentence, new line > 1847 WARNING: tab in filled text > 1642 UNSUPP: unsupported control character > 1419 STYLE: referenced manual not found > 1305 STYLE: lower case character in document title > 1111 WARNING: cannot parse date, using it verbatim > 791 STYLE: useless macro > 663 STYLE: operating system explicitly specified > 562 STYLE: no blank before trailing delimiter > 473 WARNING: invalid escape sequence > 422 ERROR: skipping excess arguments > 379 WARNING: missing date, using "" > 305 STYLE: fill mode already enabled, skipping > 249 WARNING: .so is fragile, better use ln(1) > 241 WARNING: missing manual title, using "" > 227 STYLE: trailing delimiter > 222 WARNING: unknown font, skipping request > 179 WARNING: moving content out of list > 176 WARNING: blank line in fill mode, using .sp > 173 ERROR: .so request failed > 172 WARNING: unusual Xr order > 165 WARNING: skipping no-space macro > 143 WARNING: line scope broken > 127 WARNING: skipping empty macro > 114 STYLE: normalizing date format to > 99 STYLE: unterminated quoted argument > 97 WARNING: sections out of conventional order > 82 WARNING: undefined escape, printing literally > 76 ERROR: NOT IMPLEMENTED > 75 ERROR: skipping unknown macro > 71 WARNING: wrong number of cells > 65 WARNING: missing -width in -tag list, using 6n > 61 WARNING: unusual Xr punctuation > 61 WARNING: missing section argument > 56 STYLE: verbatim "--", maybe consider using \(em > 46 WARNING: NAME section without description > 46 STYLE: function name without markup > 46 ERROR: skipping end of block that is not open > 44 WARNING: missing comma before name > 41 UNSUPP: unsupported escape sequence > 37 WARNING: prologue macros out of order > 36 WARNING: cross reference to self > 35 WARNING: moving paragraph macro out of list > 30 WARNING: empty argument, using 0n > 28 WARNING: comma in function argument > 27 STYLE: bad comment style > 26 STYLE: fill mode already disabled, skipping > 25 WARNING: content before first section header > 24 WARNING: undefined string, using "" > 21 WARNING: blocks badly nested > 21 STYLE: possible typo in section name > 21 ERROR: inserting missing end of block > 20 WARNING: unexpected section > 15 STYLE: consider using OS macro > 15 ERROR: appending missing end of block > 14 WARNING: missing Os macro, using "" > 14 WARNING: AUTHORS section without An macro > 13 WARNING: filename/section mismatch > 13 STYLE: legacy man(7) date format > 11 WARNING: nested displays are not portable > 11 ERROR: escaped character not allowed in a name > 10 WARNING: macro neither callable nor escaped > [...] > > That's certainly more warnings than in OpenBSD, but in an operating > system that is as poorly maintained as macOS, that's certainly > expected. Actually, i might have expected even more errors and > warnings. > > What can you do about it? > > Well, i would have two completely different ideas. > > First, if you find any ideas on macOS how mandoc can be improved, > reporting those is certainly welcome. The easiest way to find such > ideas is likely using mandoc on macOS for your normal work and then > noticing that something isn't working quite as it should. Like > with any other program on any other system. :-) Right. I have been using mandoc on macOS for a couple of (macOS) releases now - and as the OP said, it is the default now. It seems Apple is replacing the infrastructure with BSD tools. I don't see problems using it, except problems on the macOS side: for example, the ystill install the legacy man.conf which I have to replace with a mandoc one. > This list of errors and warnings is not the most likely starting > point for finding bugs in mandoc because most of these are more > likely issues with macOS documentation than with mandoc. Right. > The second thing you could do is trying to help improve the macOS > manual pages. I do not know whether that makes sense. Does Apple > even accept patches sent in by users? What is their policy > regarding documentation issues? Apparently one needs to read up on "Using the Feedback Assistant app" https://developer.apple.com/bug-reporting/#feedback-assistant and I for one cannot drag myself to anything like that. > Do they patch their manuals > when they are broken, or do they merely (every few decades) > pull in complete software packages from FreeBSD and other third > parties, without any local modifications? I have no idea. As an example, strlen(3) is the FreeBSD manpage from 2009. So I believe your description is pretty close. Interestingly, mandoc is not among the repos at https://opensource.apple.com/releases/ > If you use mandoc -T lint to systematically improve any collection > of manual pages, then you should generally proceed in this order: > UNSUPP, ERROR, WARNING, STYLE. UNSUPP and ERROR are almost > always worth fixing, WARNING usually, and STYLE often. On systems > other than OpenBSD and NetBSD, using -T lint -W style rather > than plain -T lint is often useful to get rid of the "base" > level warnings, which are specific convertions for OpenBSD or > NetBSD, respectively. Thanks for the insight, Jan -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Hi Jan, Jan Stary wrote on Tue, May 09, 2023 at 10:36:33AM +0200: > On Apr 04 13:09:28, anthony@anjbe.name wrote: >> From Apple's open source releases page, it appears that in macOS 13.0 >> (released last October), their man(1) implementation was replaced with >> a shell script that calls mandoc. > $ mandoc -Tlint /usr/share/man/man*/* > /tmp/lint > $ wc -l /tmp/lint > 98362 /tmp/lint > > Attached in case Ingo wants to have a look. Not quite sure what i'm supposed to do with that output... $ sed 's/^mandoc: [^ ]* //' lint | cut -d: -f1-2 | sort | uniq -c | sort -nr 53308 STYLE: input text line longer than 80 bytes 9893 STYLE: whitespace at end of input line 5629 ERROR: skipping bad character 5452 WARNING: skipping paragraph macro 4800 WARNING: empty block 4675 WARNING: new sentence, new line 1847 WARNING: tab in filled text 1642 UNSUPP: unsupported control character 1419 STYLE: referenced manual not found 1305 STYLE: lower case character in document title 1111 WARNING: cannot parse date, using it verbatim 791 STYLE: useless macro 663 STYLE: operating system explicitly specified 562 STYLE: no blank before trailing delimiter 473 WARNING: invalid escape sequence 422 ERROR: skipping excess arguments 379 WARNING: missing date, using "" 305 STYLE: fill mode already enabled, skipping 249 WARNING: .so is fragile, better use ln(1) 241 WARNING: missing manual title, using "" 227 STYLE: trailing delimiter 222 WARNING: unknown font, skipping request 179 WARNING: moving content out of list 176 WARNING: blank line in fill mode, using .sp 173 ERROR: .so request failed 172 WARNING: unusual Xr order 165 WARNING: skipping no-space macro 143 WARNING: line scope broken 127 WARNING: skipping empty macro 114 STYLE: normalizing date format to 99 STYLE: unterminated quoted argument 97 WARNING: sections out of conventional order 82 WARNING: undefined escape, printing literally 76 ERROR: NOT IMPLEMENTED 75 ERROR: skipping unknown macro 71 WARNING: wrong number of cells 65 WARNING: missing -width in -tag list, using 6n 61 WARNING: unusual Xr punctuation 61 WARNING: missing section argument 56 STYLE: verbatim "--", maybe consider using \(em 46 WARNING: NAME section without description 46 STYLE: function name without markup 46 ERROR: skipping end of block that is not open 44 WARNING: missing comma before name 41 UNSUPP: unsupported escape sequence 37 WARNING: prologue macros out of order 36 WARNING: cross reference to self 35 WARNING: moving paragraph macro out of list 30 WARNING: empty argument, using 0n 28 WARNING: comma in function argument 27 STYLE: bad comment style 26 STYLE: fill mode already disabled, skipping 25 WARNING: content before first section header 24 WARNING: undefined string, using "" 21 WARNING: blocks badly nested 21 STYLE: possible typo in section name 21 ERROR: inserting missing end of block 20 WARNING: unexpected section 15 STYLE: consider using OS macro 15 ERROR: appending missing end of block 14 WARNING: missing Os macro, using "" 14 WARNING: AUTHORS section without An macro 13 WARNING: filename/section mismatch 13 STYLE: legacy man(7) date format 11 WARNING: nested displays are not portable 11 ERROR: escaped character not allowed in a name 10 WARNING: macro neither callable nor escaped [...] That's certainly more warnings than in OpenBSD, but in an operating system that is as poorly maintained as macOS, that's certainly expected. Actually, i might have expected even more errors and warnings. What can you do about it? Well, i would have two completely different ideas. First, if you find any ideas on macOS how mandoc can be improved, reporting those is certainly welcome. The easiest way to find such ideas is likely using mandoc on macOS for your normal work and then noticing that something isn't working quite as it should. Like with any other program on any other system. :-) This list of errors and warnings is not the most likely starting point for finding bugs in mandoc because most of these are more likely issues with macOS documentation than with mandoc. If something is broken in mandoc, that's more likely to generate wrong output than to issue an error or warning message. Then again, there *might* be rare cases where error or warning messages are somehow related to mandoc mishandling the input. The second thing you could do is trying to help improve the macOS manual pages. I do not know whether that makes sense. Does Apple even accept patches sent in by users? What is their policy regarding documentation issues? Do they patch their manuals when they are broken, or do they merely (every few decades) pull in complete software packages from FreeBSD and other third parties, without any local modifications? I have no idea. If you use mandoc -T lint to systematically improve any collection of manual pages, then you should generally proceed in this order: UNSUPP, ERROR, WARNING, STYLE. UNSUPP and ERROR are almost always worth fixing, WARNING usually, and STYLE often. On systems other than OpenBSD and NetBSD, using -T lint -W style rather than plain -T lint is often useful to get rid of the "base" level warnings, which are specific convertions for OpenBSD or NetBSD, respectively. Does this anwer help? Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
[-- Attachment #1: Type: text/plain, Size: 448 bytes --] Since (apparently and approximately) 11 days ago, the prescribed cvs -d anoncvs@mandoc.bsd.lv:/cvs co mandoc invocation dies for me with cvs [checkout aborted]: end of file from server (consult above messages if any) both on CI (https://builds.sr.ht/~nabijaczleweli/job/999999) and locally. The CVSweb links (all pointing below http://mandoc.bsd.lv/cgi-bin/cvsweb/) say 500 Internal Server Error OpenBSD httpd as well. наб [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 476 bytes --] On May 09 10:27:36, hans@stare.cz wrote: > On Apr 04 13:09:28, anthony@anjbe.name wrote: > > >From Apple's open source releases page, it appears that in macOS 13.0 > > (released last October), their man(1) implementation was replaced with > > a shell script that calls mandoc. $ mandoc -Tlint /usr/share/man/man*/* > /tmp/lint $ wc -l /tmp/lint 98362 /tmp/lint Attached in case Ingo wants to have a look. Please let me know if there are specific tests to be done. Jan [-- Attachment #2: lint.gz --] [-- Type: application/x-gunzip, Size: 958475 bytes --]
On Apr 04 13:09:28, anthony@anjbe.name wrote: > >From Apple's open source releases page, it appears that in macOS 13.0 > (released last October), their man(1) implementation was replaced with > a shell script that calls mandoc. As a fallback, if mandoc gives a > -Wunsupp warning and groff is installed, the script uses groff instead. Strangely, even calling just 'man' tries to display something, saying "This manpage is not compatible with mandoc(1) and might display incorrectly" and displaying what seems to be the content of the script /usr/bin/man > https://github.com/apple-oss-distributions/man/blob/man-44/man/man.sh They also install an /etc/man.conf incompatible with mandoc. Generaly, Apple seems to be replacing the fundamental tools with *BSD tools (mostly FreeBSD, pf being a notable exception). -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Jan Stary <hans@stare.cz> writes: > That's not a problem with symlinks, > but a problem with manpage compression. > > Why would anyone compress manpages? > How much space does that save overall? [snip example] > Tens of megabytes saved, in the whole system. > Absoultely not worth the hassle. i personally agree, but here's a discussion i opened on the Gentoo bug tracker about the compression of man pages in the context of using mandoc rather than man-db: https://bugs.gentoo.org/836367 in which i linked to this old thread on mandoc-discuss: https://marc.info/?l=mandoc-discuss&m=160666427213578&w=2 and in particular Ingo's comment: https://marc.info/?l=mandoc-discuss&m=160668087317110&w=2 (This is all a result of my stubborn insistence on using mandoc on Gentoo. :-) ) Alexis. -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
> > The problem with symlinks is that they need to be updated to match
> > manpage compression. `.so` works with any compression used for the
> > manpage.
That's not a problem with symlinks,
but a problem with manpage compression.
Why would anyone compress manpages?
How much space does that save overall?
OpenBSD:
43.6M /usr/share/man/
36.6M /usr/local/man/
17.4M /tmp/man.tar.gz
macOS:
133M /Library/Developer//CommandLineTools/SDKs/MacOSX13.3.sdk/usr/share/man
25M /usr/share/man/
57M /tmp/man.tar.gz
Tens of megabytes saved, in the whole system.
Absoultely not worth the hassle.
--
To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
"G. Branden Robinson" <g.branden.robinson@gmail.com> writes: > In practice, as I understand it, `so` doesn't achieve anything > for man > pages that can't be done with symbolic links and (importantly) a > man > page indexer that is symlink-aware. Perhaps `so` support was > preserved, > and its practice retained, for a long time because at one point > in the > 1980s I think there was an AT&T/BSD split over symbolic links > even being > supported by the kernel. (And, to be fair, symbolic links are > something > of a hack that can make file system operations more painful. I > see from > the nftw() man page that they were still doing so as late as > glibc 2.30, > 3 years ago.) mgorny@gentoo.org has just pointed out that: > The problem with symlinks is that they need to be updated to > match manpage compression. `.so` works with any compression > used for the manpage. -- https://bugs.gentoo.org/905624#c1 On Gentoo, man page compression is affected by user-specified values for PORTAGE_COMPRESS and PORTAGE_COMPRESS_EXCLUDE_SUFFIXES; PORTAGE_COMPRESS is set to 'bzip2' by default. Alexis. -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
"G. Branden Robinson" <g.branden.robinson@gmail.com> writes: > In practice, as I understand it, `so` doesn't achieve anything > for man > pages that can't be done with symbolic links and (importantly) a > man > page indexer that is symlink-aware. Perhaps `so` support was > preserved, > and its practice retained, for a long time because at one point > in the > 1980s I think there was an AT&T/BSD split over symbolic links > even being > supported by the kernel. (And, to be fair, symbolic links are > something > of a hack that can make file system operations more painful. I > see from > the nftw() man page that they were still doing so as late as > glibc 2.30, > 3 years ago.) > > Does this help? Thanks, i've just opened a bug on the Gentoo bug tracker about this, "man pages for alternatives: Use of .so instead of symlink creates issue when using mandoc": https://bugs.gentoo.org/905624 in which i reference this thread. Alexis. -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Ping. Does anyone have any thoughts on this? It's a small but
persistent irritation on my system. :-)
Alexis <flexibeast@gmail.com> writes:
> [1. text/plain]
>
> Hi all,
>
> On my Gentoo system, awk.1 simply contains an .so request whose
> argument is the man page for the actual awk implementation in
> use,
> i.e. just:
>
> .so gawk.1
>
> However, although this works when using man-db, it doesn't when
> one is
> using mandoc instead, as on my system. Instead of gawk.1 being
> sourced, processed and displayed, i get output along the lines
> of:
>
> () ()
> See the file gawk.1.
>
>
> ()
>
> However, if i change the request in awk.1 to:
>
> .so man1/gawk.1
>
> then everything works as expected.
>
> The example in the entry for .so in mandoc_roff(7) is what led
> me to
> try the preceding, but there's no further indication that the
> requirement for a leading section directory is consciously
> different
> from any other roff implementation, or from groff in
> particular. A
> comment in roff_so() in mandoc/roff.c[a] says:
>
> /*
> /* Handle `so'. Be EXTREMELY careful, as we shouldn't be
> * opening anything that's not in our cwd or anything beneath
> * it. Thus, explicitly disallow traversing up the
> file-system
> * or using absolute paths.
> */
>
> i couldn't find any discussion about .so in the mandoc TODO
> list[b].
>
> i've no idea what the 'correct' behaviour 'should' be, from
> whatever
> perspective (historical / security / groff-compatibility /
> etc.), so
> am cross-posting to what i believe to be the relevant lists.
>
>
> Alexis.
>
> [a]
> https://cvsweb.bsd.lv/mandoc/roff.c?rev=1.395&content-type=text/x-cvsweb-markup
>
> [b]
> https://cvsweb.bsd.lv/mandoc/TODO?rev=1.327&content-type=text/x-cvsweb-markup
--
To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Hi all, On my Gentoo system, awk.1 simply contains an .so request whose argument is the man page for the actual awk implementation in use, i.e. just: .so gawk.1 However, although this works when using man-db, it doesn't when one is using mandoc instead, as on my system. Instead of gawk.1 being sourced, processed and displayed, i get output along the lines of: () () See the file gawk.1. () However, if i change the request in awk.1 to: .so man1/gawk.1 then everything works as expected. The example in the entry for .so in mandoc_roff(7) is what led me to try the preceding, but there's no further indication that the requirement for a leading section directory is consciously different from any other roff implementation, or from groff in particular. A comment in roff_so() in mandoc/roff.c[a] says: /* /* Handle `so'. Be EXTREMELY careful, as we shouldn't be * opening anything that's not in our cwd or anything beneath * it. Thus, explicitly disallow traversing up the file-system * or using absolute paths. */ i couldn't find any discussion about .so in the mandoc TODO list[b]. i've no idea what the 'correct' behaviour 'should' be, from whatever perspective (historical / security / groff-compatibility / etc.), so am cross-posting to what i believe to be the relevant lists. Alexis. [a] https://cvsweb.bsd.lv/mandoc/roff.c?rev=1.395&content-type=text/x-cvsweb-markup [b] https://cvsweb.bsd.lv/mandoc/TODO?rev=1.327&content-type=text/x-cvsweb-markup -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Hi, From Apple's open source releases page, it appears that in macOS 13.0 (released last October), their man(1) implementation was replaced with a shell script that calls mandoc. As a fallback, if mandoc gives a -Wunsupp warning and groff is installed, the script uses groff instead. https://opensource.apple.com/releases/ https://github.com/apple-oss-distributions/man/blob/man-44/man/man.sh -- Anthony J. Bentley -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Hi, it seems that docbook2mdoc simply uses the content of <date></date> as the text content of Dd. That's fine I guess, but mandoc -Tlint warns that e.g. STYLE: legacy man(7) date format: Dd 2022-11-16 if that's what <date> is. Is this intentionaly left to the human editor to tweak, or would it be worth it to massage such "dates" into the canonical "Dd November 16, 2022"? (I assume docbook2mdoc only does what it has to do to get out the docbook hell, not touching text content.) Jan -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
The html manpage of docbook2mdoc as linked at https://mandoc.bsd.lv/docbook2mdoc/ seems to be quite different from the output of current mandoc -Thtml docbook2mdoc.1 - the current version renders better in lynx, has no class="Op", etc. Is this intended? Jan -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
On Thu, Dec 08, 2022 at 10:19:54AM GMT, Jon Ronnenberg wrote: > Thanks for looking into this Raf. > It might be that it's an issue with my very old mac. The latest > supported OS is macOS 10.13.6 High Sierra. > > I don't have a .curlrc. But I've just upgraded curl to 7.86.0 and it > seems to work now. Yup, it seems like an older version of macOS vs certificate chain - something's missing in the former. > Sorry for the noise. NP :^) Regards, Raf -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Thanks for looking into this Raf. It might be that it's an issue with my very old mac. The latest supported OS is macOS 10.13.6 High Sierra. I don't have a .curlrc. But I've just upgraded curl to 7.86.0 and it seems to work now. curl -vI https://mandoc.bsd.lv/snapshots/mandoc-1.14.6.tar.gz * Trying 66.111.2.12:443... * Connected to mandoc.bsd.lv (66.111.2.12) port 443 (#0) * ALPN: offers h2 * ALPN: offers http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN: server did not agree on a protocol. Uses default. * Server certificate: * subject: CN=bsd.lv * start date: Nov 5 07:30:24 2022 GMT * expire date: Feb 3 07:30:23 2023 GMT * subjectAltName: host "mandoc.bsd.lv" matched cert's "mandoc.bsd.lv" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. > HEAD /snapshots/mandoc-1.14.6.tar.gz HTTP/1.1 > Host: mandoc.bsd.lv > User-Agent: curl/7.86.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK HTTP/1.1 200 OK < Connection: keep-alive Connection: keep-alive < Content-Length: 697150 Content-Length: 697150 < Content-Type: application/octet-stream Content-Type: application/octet-stream < Date: Thu, 08 Dec 2022 10:12:29 GMT Date: Thu, 08 Dec 2022 10:12:29 GMT < Last-Modified: Thu, 23 Sep 2021 18:03:53 GMT Last-Modified: Thu, 23 Sep 2021 18:03:53 GMT < Server: OpenBSD httpd Server: OpenBSD httpd < * Connection #0 to host mandoc.bsd.lv left intact Sorry for the noise. On Wed, Dec 7, 2022 at 10:52 PM Raf Czlonka <rczlonka@gmail.com> wrote: > > Hi Jon, > > On Wed, Dec 07, 2022 at 07:35:07PM GMT, Jon Ronnenberg wrote: > > Here is what I get from curl 7.54.0: > > > > curl -vI https://mandoc.bsd.lv/snapshots/mandoc-1.14.6.tar.gz > > Trying 66.111.2.12... > > TCP_NODELAY set > > Connected to mandoc.bsd.lv (66.111.2.12) port 443 (#0) > > ALPN, offering h2 > > ALPN, offering http/1.1 > > Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > > Is the above set in your .curlrc? > > > successfully set certificate verify locations: > > CAfile: /etc/ssl/cert.pem > > CApath: none > > TLSv1.2 (OUT), TLS handshake, Client hello (1): > > TLSv1.2 (IN), TLS handshake, Server hello (2): > > TLSv1.2 (IN), TLS handshake, Certificate (11): > > TLSv1.2 (OUT), TLS alert, Server hello (2): > > SSL certificate problem: certificate has expired > > stopped the pause stream! > > Closing connection 0 > > curl: (60) SSL certificate problem: certificate has expired > > I can't reproduce it - it works fine with curl packages for > OpenBSD-current, macOS 13.0.1, and Ubuntu 20.04 LTS. > > Regards, > > Raf > -- > To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv > -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Hi Jon, On Wed, Dec 07, 2022 at 07:35:07PM GMT, Jon Ronnenberg wrote: > Here is what I get from curl 7.54.0: > > curl -vI https://mandoc.bsd.lv/snapshots/mandoc-1.14.6.tar.gz > Trying 66.111.2.12... > TCP_NODELAY set > Connected to mandoc.bsd.lv (66.111.2.12) port 443 (#0) > ALPN, offering h2 > ALPN, offering http/1.1 > Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH Is the above set in your .curlrc? > successfully set certificate verify locations: > CAfile: /etc/ssl/cert.pem > CApath: none > TLSv1.2 (OUT), TLS handshake, Client hello (1): > TLSv1.2 (IN), TLS handshake, Server hello (2): > TLSv1.2 (IN), TLS handshake, Certificate (11): > TLSv1.2 (OUT), TLS alert, Server hello (2): > SSL certificate problem: certificate has expired > stopped the pause stream! > Closing connection 0 > curl: (60) SSL certificate problem: certificate has expired I can't reproduce it - it works fine with curl packages for OpenBSD-current, macOS 13.0.1, and Ubuntu 20.04 LTS. Regards, Raf -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Thank you for responding so quickly! Will you write here when the
certificate has been updated? Currently `brew install openssh` is
b0rken - and surely many other other "brews" that depends on mandoc.
On Wed, Dec 7, 2022 at 9:14 PM Kristaps Dzonsons <kristaps@bsd.lv> wrote:
>
> That's my fault for not updating the box in a hot second... I'll get us
> up to speed asap, which will pull the newest ACME certs. Thank you for
> reporting this!
>
> On 12/7/22 11:35, Jon Ronnenberg wrote:
> > Here is what I get from curl 7.54.0:
> >
> > curl -vI https://mandoc.bsd.lv/snapshots/mandoc-1.14.6.tar.gz
> > Trying 66.111.2.12...
> > TCP_NODELAY set
> > Connected to mandoc.bsd.lv (66.111.2.12) port 443 (#0)
> > ALPN, offering h2
> > ALPN, offering http/1.1
> > Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
> > successfully set certificate verify locations:
> > CAfile: /etc/ssl/cert.pem
> > CApath: none
> > TLSv1.2 (OUT), TLS handshake, Client hello (1):
> > TLSv1.2 (IN), TLS handshake, Server hello (2):
> > TLSv1.2 (IN), TLS handshake, Certificate (11):
> > TLSv1.2 (OUT), TLS alert, Server hello (2):
> > SSL certificate problem: certificate has expired
> > stopped the pause stream!
> > Closing connection 0
> > curl: (60) SSL certificate problem: certificate has expired
> > --
> > To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
> >
> --
> To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
>
--
To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv