From: Mike Frysinger <vapier@gentoo.org>
To: linux-man@vger.kernel.org
Subject: preferred /proc/<pid>/xxx style?
Date: Fri, 9 Dec 2022 18:41:05 +0900 [thread overview]
Message-ID: <Y5MCsc/H9BV6RcST@vapier> (raw)
[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]
while browsing time_namespaces(7), i noticed it's inconsistent when it comes to
styling of /proc/<pid>/paths. it uses the styles:
* .IR /proc/ pid /ns/time_for_children
* .I /proc/PID/timens_offsets
grepping the tree turns up more:
* .I /proc/<pid>/maps
* .I /proc/[pid]/status
it seems that the tree is moving towards the first style. personally i find
that jarring to read because it's using italics for the whole path except for
the pid which has no styling at all. in the terminal this yields colored &
underlined text except for the "pid" which is just plain text like the rest.
commit 1ae6b2c7b818e5d8804cf8d3abfdb6fba32119db made a large change recently
to proc(5) to use .IR, but with no explanation in the commit message other
than to satisfy a linter, and running that linter locally doesn't seem to show
any warnings when using the previous /proc/[pid] style.
the man-pages(7) guidance doesn't covert this afaict. it has:
> Formatting conventions (general)
> Filenames (whether pathnames, or references to header files) are always in italics ...
that implies it should be only in italics.
if we look a bit further, using .IR seems inconsistent.
> SYNOPSIS
> For commands, this shows the syntax of the command and its arguments (including options);
> boldface is used for as-is text and italics are used to indicate replaceable arguments
>
> Formatting conventions for manual pages describing commands
> For manual pages that describe a command (...), the arguments are always specified using italics
>
> Formatting conventions for manual pages describing functions
> For manual pages that describe functions (...), the arguments are always specified using italics,
> even in the SYNOPSIS section, where the rest of the function is specified in bold:
-mike
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2022-12-09 9:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 9:41 Mike Frysinger [this message]
2022-12-09 19:43 ` preferred /proc/<pid>/xxx style? Alejandro Colomar
2022-12-09 21:03 ` G. Branden Robinson
2022-12-09 21:09 ` words (and commands) that I learnt because of Branden (was: preferred /proc/<pid>/xxx style?) Alejandro Colomar
2022-12-09 22:10 ` Deri
[not found] ` <CAGcdajfWk+=xR3UfAnNri0F7OL0mFJ4xsp=sQoWLo_-_G5wcBA@mail.gmail.com>
2022-12-10 7:15 ` hbezemer
2022-12-10 8:57 ` G. Branden Robinson
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=Y5MCsc/H9BV6RcST@vapier \
--to=vapier@gentoo.org \
--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