Linux Manual Pages development
 help / color / mirror / Atom feed
From: DJ Delorie <dj@redhat.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: alx@kernel.org, linux-man@vger.kernel.org
Subject: Re: man/man8/ldconfig.8: document system-wide tunables
Date: Wed, 15 Jul 2026 16:46:46 -0400	[thread overview]
Message-ID: <xnldbc6kw9.fsf@greed.delorie.com> (raw)
In-Reply-To: <20260715194711.mcdsgtt4x37cwdum@illithid> (g.branden.robinson@gmail.com)

"G. Branden Robinson" <g.branden.robinson@gmail.com> writes:
>> > The man(7) package doesn't impose a rigid stylesheet on its output.
>> 
>> Perhaps, but the fact that I now know about the rule, and the
>> exception, means that it's not entirely flexible either ;-)
>
> The man(7) macro language is not highly flexible, no,

Sorry, I meant the man-pages style guide rules, not roff itself.

>> In this case, it does sound like the man pages need a different thing
>> for "example code" (.EX) and "preformatted text" (html's <PRE>).
>
> A common error is to assume that `EX` implies `<PRE>`.  It doesn't.

I just meant for semantic context, like "this is a code snippet" vs "I
want this to be formatted the way I typed it."  Might be helpful when
outputting HTML/CSS, like the examples would be in boxes and shaded with
the usual "copy to paste buffer" button, but <pre> would just be
monospaced and unformatted.  But thus is the slippery slope that led to
XML, and we don't want that again.

>> glibc uses texinfo, which is TeX but terminals don't have **** off ;-)
>
> Yes.  And info(1) sometimes produces...intriguing results.

My preference here is PDF, as we make sure all the cross refs and TOC
work correctly, and it formats very nicely (duh, TeX).  Info is useful
in emacs only because my fingers are already on the keyboard.

>> I don't write programs in assembly either (well, usually ;).
>
> No indeed.  The real "assembly language" of troff is its
> "device-independent output", which for short I call "trout" if it's
> Kernighan's original spec from CSTR #97 in 1982, or "grout" if it
> features groff's extensions.

I've been accused of abusing my own namespace here.  I would have called
my version "djrout".

> Yes, but people get _really wedded_ to the specifics of rendering even
> after setting aside the huge issue of terminal width.

I once worked for a guy who, at one point, wrote a typesetter that went
between satellites and the New York Times.  The typesetting had to be
perfect, every time, and run at line speed.  I learned a lot from him,
and he's the reason I have my own copy of the Chicago Manual of Style
and know what Reverse Boustrophedon is.

Also, Team Oxford Comma!

>> (wait, when did "man -l" happen?  Have I been missing that all along?
>> Is my script really that old?)
>
> In the man-db implementation of man(1), it seems to date back to _at
> least_ 2002, as I see a Git commit for it (imported from CVS or

I might predate even that.

> If you are/were using Red Hat/RPM-based systems, you may have been using
> Brouwer/Lucifredi man(1), which as far as I know never implemented this
> `-l` option.  After that implementation lay moribund for many years,

RHEL 9 has "man -l" via man.man-db at least, but that's today.


  reply	other threads:[~2026-07-15 20:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 18:53 man/man8/ldconfig.8: document system-wide tunables DJ Delorie
2026-07-10 14:31 ` Alejandro Colomar
2026-07-10 18:12   ` DJ Delorie
2026-07-10 19:58     ` Why we're stuck with man(7) (was: man/man8/ldconfig.8: document system-wide tunables) G. Branden Robinson
2026-07-10 22:11       ` DJ Delorie
2026-07-10 22:28         ` Alejandro Colomar
2026-07-10 22:19       ` DJ Delorie
2026-07-10 20:06     ` man/man8/ldconfig.8: document system-wide tunables Alejandro Colomar
2026-07-10 20:33       ` Alejandro Colomar
2026-07-13 16:24         ` DJ Delorie
2026-07-13 20:16           ` Alejandro Colomar
2026-07-13 21:33             ` DJ Delorie
2026-07-13 22:22               ` G. Branden Robinson
2026-07-14  6:56                 ` G. Branden Robinson
2026-07-15  2:34                   ` DJ Delorie
2026-07-15 12:47                     ` Alejandro Colomar
2026-07-15 14:33                       ` DJ Delorie
2026-07-15 16:54                         ` G. Branden Robinson
2026-07-15 18:19                           ` DJ Delorie
2026-07-15 19:47                             ` G. Branden Robinson
2026-07-15 20:46                               ` DJ Delorie [this message]
2026-07-15 21:09                             ` Alejandro Colomar
2026-07-15 21:46                               ` DJ Delorie
2026-07-15 17:09                         ` Alejandro Colomar
2026-07-15 18:55                           ` DJ Delorie
2026-07-13 22:53               ` Alejandro Colomar

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xnldbc6kw9.fsf@greed.delorie.com \
    --to=dj@redhat.com \
    --cc=alx@kernel.org \
    --cc=g.branden.robinson@gmail.com \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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