Rationale:
$ man 7 man-pages 2>/dev/null | sed -n /Paragraphs/,/^$/p
Paragraphs should be separated by suitable markers (usually
either .PP or .IP). Do not separate paragraphs using blank
lines, as this results in poor rendering in some output
formats (such as PostScript and PDF).
Fix:
$ sed -i -e '1,/^\.EX/s/^$/.PP/' -e '/^\.EE/,/^\.EX/s/^$/.PP/' man?/*
And then some manual adjustments.
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I noticed this while working on some silly "hello, world"
programs, see https://git.sr.ht/~phf/hello-again if you're
curious. Disassembling sh4 code showed trap #31 all over the
place but the syscall(2) man page talked about trap #0x17 and
friends. Checking the kernel sources I got lucky in
arch/sh/kernel/entry-common.S where in commit 3623d138213ae Rich
Felker clarifies the situation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Cc: Martin Sebor <msebor@redhat.com>
Cc: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Files moved from .txt to .rst.
Also, drop / prefix from kernel source tree references.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The main point I was driving at with this patch was to fix
"Microsoft Window's FAT filesystems" (i.e., FAT filesystems which
belong to Microsoft Windows, which is decidedly wrong).
FAT32 first shipped with MS-DOS 7.1, as part of Windows 95 OSR2,
but it's a (relatively) simple logical extension of the previous
FATx filesystems (16 and 12 as we know and love them today, I
don't think the PC ever saw 8), hence the "VFAT" driver name ‒
calling FAT-anything a Windows filesystem would be a flat-out lie,
calling it a Microsoft filesystem would be, uh, facetious.
NTFS (as part of Windows NT), on the other hand, is wholly
different WRT the scope and feature-set (it does borrow some
layouting from FAT, but reading NTFS as FAT doesn't get you very
far, or much).
The replacing bit is also questionable, especially in a.d. 2020:
while it is true that you cannot install NT on FAT (after a
certain point? my memory ain't what it used to be), and must
therefore replace your existing FAT partitions with NTFS during
upgrades; Windows NT 4.0, the last product to be NT-branded came
out in 1996, i.e. you could not install Windows on FAT (and,
therefore, upgrade it to NTFS, replacing it) during my entire
lifetime.
Indeed, in $(date +%Y) we live in a post-NTFS world ‒ putting NTFS
in the same class as FAT beyond "is a filesystem" is a joke.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Relevant Linux commits:
* moved to staging in 1bb8155080c652c4853e6228f8f0d262b3049699
(describe: v4.15-rc1-129-g1bb8155080c6) in Nov 2017,
described as "broken" and "obsolete"
* purged in bd32895c750bcd2b511bf93917bf7ae723e3d0b6
(describe: v4.17-rc3-1010-gbd32895c750b) in Jun 2018,
"since no one has complained or even noticed it was gone"
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Jakub Wilk