All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: наб <nabijaczleweli@nabijaczleweli.xyz>
Cc: Seth McDonald <sethmcmail@pm.me>, linux-man@vger.kernel.org
Subject: Re: [RFC PATCH v1 1/2] src/bin/sman: Add script
Date: Wed, 28 Jan 2026 18:19:18 +0100	[thread overview]
Message-ID: <aXpB44YBOSY5MMA7@devuan> (raw)
In-Reply-To: <xclnrhc3q3kub6gqhd64difkyls74zcqmhnpwov2dwzrsghjg3@tarta.nabijaczleweli.xyz>

[-- Attachment #1: Type: text/plain, Size: 2934 bytes --]

Hi наб,

On 2026-01-28T17:52:15+0100, наб wrote:
> You wrote it confusingly (if I wrote it like that it'd be on purpose;
>  I doubt that was your intent but that's how it reads),
> so I isomorphised your program into third normal form:
> -- >8 --
> #!/bin/sh
> #
> # Copyright, the authors of the Linux man-pages project
> # SPDX-License-Identifier: GPL-3.0-or-later
> 
> name="${0##*/}"

I find basename(1) much more readable.  Also, it's easier to find
documentation about it.

> 
> # fail [error message]
> fail() {
> 	[ $# -gt 1 ] && echo "$name: $1"

I agree [(1) is more readable than '[[...]]'.  I prefer test(1), though.

[...]
> -- >8 --
> 
> Then I made it behave acceptably thusly:
> -- >8 --
[...]
> -- >8 --

[...]
> If you were shipping this you'd want to do the filtering in one pass
> because the UX of the sections being out of order is IMO suboptimal.
> And also processing and fully-bufferring the /whole/ rendered output,
> for big pages, is so slow
> (I tested on voreutils ls(1) ‒ <https://ro.ws.co.ls/man1/ls.1.pdf>
>  time man ls > /dev/null takes 0m0.513s wall clock;
>  multiply this for each section, and you see how this is suboptimal;
>  similarly, voreutils stty(1) measures 0m1.620s;
>  this is especially suboptimal since big complex pages are exactly the
>  ones you'd want to filter;
>  also, I think this wants a negative section filter as well
>  (to remove HISTORY or STANDARDS which may be less relevant))

In mansect(1) (see below), you can do negative filtering if you want,
by writing a complex-enough PCRE2 pattern that rejects some name(s).

> you can work around this a little by sticking a load of stdbuf -oL
> on the pipeline, but, again, I think the final for loop should be
> representable as a one-shot AWK program.

It is, and indeed, that's how I implemented mansect(1).  Well, I used
pcre2grep(1) instead of awk(1), but it is a one-shot program.

	alx@devuan:~/src/linux/man-pages/man-pages/master$ cat src/bin/mansect 
	#!/bin/bash
	#
	# Copyright, the authors of the Linux man-pages project
	# SPDX-License-Identifier: GPL-3.0-or-later

	set -Eefuo pipefail;


	if test $# -lt 1; then
		>&2 printf '%s\n' "$(basename "$0"): error: Too few arguments."
		exit 1;
	fi;

	s="$1";
	shift;

	if test $# -lt 1; then
		preconv;
	else
		find -H "$@" -not -type d \
		| xargs preconv;
	fi \
	| pcre2grep -M \
		-e '^\.lf 1 ' \
		-e '^\.TH ' \
		-e '(?s)^\.SH ('"$s"')$(?:(?!^\.(lf 1|TH|SH) ).)*';

And as I suggested in the other sub-thread, we can just pipe this to
a formatter to get the intended behavior:

	$ cat src/bin/mansectf 
	#!/bin/bash
	#
	# Copyright, the authors of the Linux man-pages project
	# SPDX-License-Identifier: GPL-3.0-or-later

	set -Eefuo pipefail;

	mansect "$@" \
	| man /dev/stdin;


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-01-28 17:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27  9:20 [RFC PATCH v1 0/2] New sman(1) script Seth McDonald
2026-01-27  9:20 ` [RFC PATCH v1 1/2] src/bin/sman: Add script Seth McDonald
2026-01-28 16:52   ` наб
2026-01-28 17:19     ` Alejandro Colomar [this message]
2026-01-28 19:07     ` G. Branden Robinson
2026-01-28 22:02       ` наб
2026-01-28 22:31         ` G. Branden Robinson
2026-01-27  9:20 ` [RFC PATCH v1 2/2] man/man1/sman.1: Add man page Seth McDonald
2026-01-27 13:47 ` [RFC PATCH v1 0/2] New sman(1) script Alejandro Colomar
2026-01-28  4:44   ` Seth McDonald
2026-01-28  5:48     ` G. Branden Robinson
2026-01-28 14:36       ` Alejandro Colomar
2026-01-28 14:47     ` Alejandro Colomar
2026-01-28 18:55 ` [PATCH v2] src/bin/mansectf, man/man1/mansectf.1: Add program and manual page Alejandro Colomar
2026-01-29  5:50   ` Seth McDonald
2026-01-29 11:27     ` Alejandro Colomar
2026-01-29 14:31     ` New PARAMETERS section in manual pages (was: [PATCH v2] src/bin/mansectf, man/man1/mansectf.1: Add program and manual page) Alejandro Colomar
2026-01-29 20:24       ` G. Branden Robinson
2026-01-29 22:06         ` Alejandro Colomar
2026-01-29 22:20           ` 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=aXpB44YBOSY5MMA7@devuan \
    --to=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=nabijaczleweli@nabijaczleweli.xyz \
    --cc=sethmcmail@pm.me \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.