From: Jan Stary <email@example.com>
Subject: Re: Mandoc for oil
Date: Fri, 14 Jun 2019 13:40:07 +0200 [thread overview]
Message-ID: <20190614114006.GB77287@www.stare.cz> (raw)
On Jun 14 05:24:23, firstname.lastname@example.org wrote:
> I was concerned that if I wrote osh.1 in mdoc(7), I would need to
> generate another man(7) page for systems that don't support mdoc(7), ie
> most linuxes.
Linux systems do "support" mdoc(7): the linux man(1) runs groff(1)
to format the manpage, and groff(1) understands both mdoc(7) and man(7).
> But isn't the point of mandoc -T man to output man(7) from an
> mdoc(7) file?
No. An mdoc(7) manpage can be readily displayed
(by mandoc, by groff, by the linux man via groff).
Just like a man(7) page can.
> Or asking another way; what's the most reasonable (workflow) way to write
> a man page in mdoc(7),
$ vi prog.1
$ vi function.3
$ vi format.5
> but make man pages available on systems that don't
> support mdoc(7) (ie most linuxes)?
They do, see above.
mdoc(7) is not a novelty, it has been around for decades.
See the excelent https://manpages.bsd.lv/history.html
(which is interesting in itself).
> > > A good start is
> > >
> > > $ wc -l /usr/share/man/man1/*.1 | sort -n | less
> > >
> > > (or wherever your system keeps manpages),
> > > pick the shortest one for a program you know and use,
> > > and read the (input) manpage, such as
> > >
> > > $ vim /usr/share/man/man1/yes.1
> > I forgot an important thing: on many systems outside of the *BSD family,
> > the system manpages will be written in the legacy man(7) format,
> > built on top of roff(7), a general purpose typesetting language.
> > Both man(1) and mandoc(1) can read both; but mdoc(5) ficilitates
> > semantic markup ("this is a commandline option"), as opposed to
> > low-level formating instructions ("type this in italic").
> > In case your system uses man(7), not mdoc(7), as e.g. most linuxes do,
> > you will have to learn mdoc elsewhere, e.g.
> > http://cvsweb.openbsd.org/src/usr.bin/yes/yes.1
To unsubscribe send an email to email@example.com
next prev parent reply other threads:[~2019-06-14 11:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-14 8:16 Matthew Singletary
2019-06-14 8:43 ` Jan Stary
2019-06-14 8:54 ` Jan Stary
2019-06-14 9:24 ` Matthew Singletary
2019-06-14 11:40 ` Jan Stary [this message]
2019-06-14 12:29 ` Ingo Schwarze
2019-06-14 13:08 ` Jan Stary
2019-06-14 14:27 ` Jan Stary
2019-06-14 14:54 ` Ingo Schwarze
2019-06-16 2:39 ` Matthew Singletary
2019-06-16 17:08 ` Ingo Schwarze
2019-06-14 9:54 ` Stephen Gregoratto
2019-06-14 12:03 ` Jan Stary
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).