Call the groff(1) pipeline only once. This optimizes around 2 seconds,
while also simplifying the code.
This change was originally written by Deri, with some parts written by
Brian. I took the script that Deri sent, and split it so that the
groff(1) pipeline is called from the shell script, and the Perl script
is limited to editing the man(7) pages. This helps me understand the
process, since my understanding of Perl is very limited. It also makes
this change smaller, so that it's less of a big-bang.
Link: <https://lore.kernel.org/linux-man/ZWkO4qPC4BxkwBNm@debian/T/#m3d453440b02dd189bc12d2e629c4026206025b40> Co-developed-by: Deri James <deri@chuzzlewit.myzen.co.uk> Co-developed-by: Brian Inglis <Brian.Inglis@Shaw.ca> Signed-off-by: Alejandro Colomar <alx@kernel.org>
scripts/LinuxManBook/prepare_linux_man_book.pl: Add new function BuildSec()
The intention is to move some code from BuildPage() into this function,
reducing the complexity of that inner function. As a side effect, just
by adding this function, I've already noticed an optimization of 0.3 s.
The reason, I guess, is that it starts processing pages without waiting
for the entire sort to complete, which reduces the latency of the script.
Cc: Deri James <deri@chuzzlewit.myzen.co.uk> Signed-off-by: Alejandro Colomar <alx@kernel.org>
scripts/LinuxManBook/build_linux_man_book.sh: Call pic(1), and call it after preconv(1)
Call it, just in case we want to use in manual pages in the future. It
doesn't hurt performance. And call it after preconv(1), which should be
the first program in the groff(1) pipeline.
Suggested-by: Deri James <deri@chuzzlewit.myzen.co.uk> Signed-off-by: Alejandro Colomar <alx@kernel.org>
We're suppressing formatted device-independent output of troff(1),
so it doesn't make sense to pass an option to gropdf(1) with -P.
We don't need the fonts either. We don't even need groff(1), since
we're only using troff(1).
Redirect to /dev/null, instead of using -z. It's more explicit.
scripts/LinuxManBook/build_linux_man_book.sh: Use pipes instead of temporary files
It's still easy to debug, by inserting |tee /dev/tty|, but the script
is cleaner if it doesn't generate intermediary files, and it's also
faster (on my desktop computer, it goes down from 18.5 s to 16.3 s).
stpncpy.3: EXAMPLES: Use fwrite(3) instead of printf(3)
fwrite(3) is more appropriate for printing a character sequence with
known lenght. printf(3) has a limitation of INT_MAX, and also requires
more complex (less readable) code.
Suggested-by: Paul Eggert <eggert@cs.ucla.edu> Cowritten-by: Paul Eggert <eggert@cs.ucla.edu> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Format only one man page cross reference per input line.
Begin parentheticals on their own input lines.
Also, groff 1.23.0's (and Plan 9 from User Space's) `MR` is not a font
style alternation macro; there is no "reversed" form as with `BR` and
`RB`. So when a man page cross reference must be immediately preceded
by punctuation, put that punctuation on the previous text line and use
the `\c` escape sequence to connect them.
Elliott Hughes [Tue, 14 Nov 2023 00:46:43 +0000 (16:46 -0800)]
ffs.3: All these functions live in <strings.h>.
In most cases you'll get them transitively through <string.h>, but it's
misleading for the man page to claim that they're _in_ <string.h>, and
especially weird to claim they're in _different_ headers from each
other!
This is also true of Apple's headers, and FreeBSD (the other BSDs only
have ffs(), not its siblings).
Paul Eggert [Mon, 13 Nov 2023 22:26:42 +0000 (14:26 -0800)]
string.3: strncpy(): wfix
Say "size" not "width" for byte counts; "width" is for the number of
bits in a word. Say "leading" to make it clear we don’t care about what
the source contains after its first null byte.
string.3: strncpy(): Talk about bytes, not characters
These functions are also the way to copy multibyte strings, so be
generic and say that they just copy bytes. Not every byte is a valid
character in (for example) UTF-8 locales.
Cowritten-by: Paul Eggert <eggert@cs.ucla.edu> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Add this new truncating string-copying function. It intends to fully
replace strlcpy(3), which has important bugs (documented in the
preceeding commit).
It is almost identical to Linux kernel's strscpy(9), so reduce the
documentation of strscpy(9) in this page to the minimum, giving
preference to strtcpy(3). Provide a reference implementation, since no
libc provides it.
Providing an easy, safe, and relatively fast truncating string-copying
function should prevent users from rolling their own, in which they
might introduce bugs accidentally. We already made enough mistakes
while discussing these functions, so it's certainly not something that
should be written often.
Cc: Paul Eggert <eggert@cs.ucla.edu> Cc: Jonny Grant <jg@jguk.org> Cc: DJ Delorie <dj@redhat.com> Cc: Matthew House <mattlloydhouse@gmail.com> Cc: Oskari Pirhonen <xxc3ncoredxx@gmail.com> Cc: Thorsten Kukuk <kukuk@suse.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Zack Weinberg <zack@owlfolio.org> Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com> Cc: Carlos O'Donell <carlos@redhat.com> Cc: Xi Ruoyao <xry111@xry111.site> Cc: Stefan Puiu <stefan.puiu@gmail.com> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Guillem Jover <guillem@hadrons.org> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Also point to BUGS from other sections that talk about these functions.
These functions are doomed due to the design decision of mirroring
snprintf(3)'s return value. They must return strlen(src), which makes
them terribly slow, and vulnerable to DoS if an attacker can control
strlen(src).
A better design would have been to return -1 when truncating.
Reported-by: Paul Eggert <eggert@cs.ucla.edu> Cc: Jonny Grant <jg@jguk.org> Cc: DJ Delorie <dj@redhat.com> Cc: Matthew House <mattlloydhouse@gmail.com> Cc: Oskari Pirhonen <xxc3ncoredxx@gmail.com> Cc: Thorsten Kukuk <kukuk@suse.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Zack Weinberg <zack@owlfolio.org> Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com> Cc: Carlos O'Donell <carlos@redhat.com> Cc: Xi Ruoyao <xry111@xry111.site> Cc: Stefan Puiu <stefan.puiu@gmail.com> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Guillem Jover <guillem@hadrons.org> Signed-off-by: Alejandro Colomar <alx@kernel.org>
string_copying.7: BUGS: *cat(3) functions aren't always bad
The compiler will sometimes optimize them to normal *cpy(3) functions,
since the length of dst is usually known, if the previous *cpy(3) is
visible to the compiler. And they provide for cleaner code. If you
know that they'll get optimized, you could use them.
Cc: Paul Eggert <eggert@cs.ucla.edu> Cc: Jonny Grant <jg@jguk.org> Cc: DJ Delorie <dj@redhat.com> Cc: Matthew House <mattlloydhouse@gmail.com> Cc: Oskari Pirhonen <xxc3ncoredxx@gmail.com> Cc: Thorsten Kukuk <kukuk@suse.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Zack Weinberg <zack@owlfolio.org> Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com> Cc: Carlos O'Donell <carlos@redhat.com> Cc: Xi Ruoyao <xry111@xry111.site> Cc: Stefan Puiu <stefan.puiu@gmail.com> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org>
stpncpy.3, string.3, string_copying.7: Clarify that st[rp]ncpy() pad with null bytes
The previous wording could be interpreted as if the nulls were already
in place. Clarify that it's this function which pads with null bytes.
Also, it copies "characters" from the src string. That's a bit more
specific than copying "bytes", and makes it clearer that the terminating
null byte in src is not part of the copy.
Suggested-by: Jonny Grant <jg@jguk.org> Cc: DJ Delorie <dj@redhat.com> Cc: Matthew House <mattlloydhouse@gmail.com> Cc: Oskari Pirhonen <xxc3ncoredxx@gmail.com> Cc: Thorsten Kukuk <kukuk@suse.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Zack Weinberg <zack@owlfolio.org> Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com> Cc: Carlos O'Donell <carlos@redhat.com> Cc: Paul Eggert <eggert@cs.ucla.edu> Cc: Xi Ruoyao <xry111@xry111.site> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Fixes: 17282a589f2f ("posixoptions.7: Make function lists more consistent and less cluttered") Reported-by: Helge Kreutzmann <debian@helgefjell.de> Cc: Mario Blaettermann <mario.blaettermann@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Bruno Haible [Sun, 29 Oct 2023 20:46:49 +0000 (21:46 +0100)]
prctl.2: Use a better term
The first argument of prctl() was denoted as "option" here. This makes
no sense, because
- The first argument is not optional; it is mandatory.
A choice is an "option" only if it is possible to choose none of
the available choices.
- The title of the page is "operations on a process or thread".
A better term is "operation".
Cc: Stefan Puiu <stefan.puiu@gmail.com> Acked-by: Elliott Hughes <enh@google.com> Signed-off-by: Bruno Haible <bruno@clisp.org> Signed-off-by: Alejandro Colomar <alx@kernel.org>
The feature was added on glibc 2.33 as a way to improve the path search,
since the legacy hardware capabilities combination scheme does not scale
properly with new hardware support. The legacy support was removed non
glibc 2.37, so it is the only scheme currently supported.
man*/: ffix (Place short options after long options)
This increases the chances that the paragraph will start in the same
line as the tag, wasting less vertical space.
The result seems visually better to me.
On Wed, Oct 25, 2023 at 09:11:03AM -0500, G. Branden Robinson wrote:
> I also like your suggestion that if we really want to economize on
> space, we could present a command's long option form before its short,
> old-style Unix synonym, which will work well when the short option (plus
> its argument, if any) fits within the space for the paragraph tag. This
> might be a good idea for another reason; in GNU user space, the long
> option is the much more self-documenting form, and the single-character
> option name a kind of "expert mode" alternative. As a general rule,
> when presenting technical material, one should not lead with "expert
> mode".
Don Brace [Wed, 25 Oct 2023 14:22:35 +0000 (09:22 -0500)]
smartpqi.4: HISTORYise sysfs entry "version"
Remove the "version" sysfs entry. This entry was changed into
two sysfs entries: driver_version and firmware_version by
patch "(6d90615f1346 scsi: smartpqi: add sysfs entries)" in Linus's
tree Aug 22 2019.
Add HISTORY section.
Enumerate old sysfs entries replaced by newer entries.
Don Brace [Tue, 24 Oct 2023 22:01:53 +0000 (17:01 -0500)]
smartpqi.4: Add device attributes
Add in some device level sysfs entry descriptions:
lunid
unique_id
path_info
raid_bypass_cnt
sas_ncq_prio_enable
These have already been provided by the driver.
Reviewed-by: Scott Benesh <scott.benesh@microchip.com> Reviewed-by: Scott Teel <scott.teel@microchip.com> Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com> Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com> Signed-off-by: Don Brace <don.brace@microchip.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Don Brace [Tue, 24 Oct 2023 22:01:51 +0000 (17:01 -0500)]
smartpqi.4: Say "volumes" instead of "drives"
Change the word "drives" to "volumes" to match our documentation and how
they are presented to SCSI Mid-layer: as "LOGICAL VOLUMES".
I.E.
[0:1:0:0] disk HP LOGICAL VOLUME 7.02 /dev/sdc
Reviewed-by: Scott Benesh <scott.benesh@microchip.com> Reviewed-by: Scott Teel <scott.teel@microchip.com> Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com> Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com> Signed-off-by: Don Brace <don.brace@microchip.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
When there are multiple tags for a paragraph, using a single TP and
separating the tags with commas makes the man(7) source more complex.
It also has a disadvantage: when searching through a manual page,
heuristics such as " --option" don't work so well.
By using GNU's TQ, we simplify the source of the pages, and improve the
ability to search them.