[PATCH 01/10] fanotify_init.2: tfix

[PATCH 01/10] fanotify_init.2: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man2/fanotify_init.2 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/man2/fanotify_init.2 b/man2/fanotify_init.2
index 9eac6d2d7..262c505fa 100644
--- a/man2/fanotify_init.2
+++ b/man2/fanotify_init.2
@@ -186,7 +186,7 @@ objects by file handles.
 Note that without the flag
 .BR FAN_REPORT_TARGET_FID ,
 for the directory entry modification events,
-there is an inforamtion record that identifies the modified directory
+there is an information record that identifies the modified directory
 and not the created/deleted/moved child object.
 The use of
 .B FAN_CLASS_CONTENT
@@ -477,7 +477,7 @@ users may call
 .BR fanotify_init ()
 without the
 .B CAP_SYS_ADMIN
-capability to create and intialize an fanotify group with limited functionality.
+capability to create and initialize an fanotify group with limited functionality.
 .TP
 The limitations imposed on an event listener created by a user without the
 .B CAP_SYS_ADMIN
-- 
2.37.2

[PATCH 02/10] landlock_restrict_self.2: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man2/landlock_restrict_self.2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man2/landlock_restrict_self.2 b/man2/landlock_restrict_self.2
index b83f3bedb..32ace3b26 100644
--- a/man2/landlock_restrict_self.2
+++ b/man2/landlock_restrict_self.2
@@ -33,7 +33,7 @@ A domain can only be updated in such a way that
 the constraints of each past and future composed rulesets
 will restrict the thread and its future children for their entire life.
 It is then possible to gradually enforce tailored access control policies
-with multiple independant rulesets coming from different sources
+with multiple independent rulesets coming from different sources
 (e.g., init system configuration, user session policy,
 built-in application policy).
 However, most applications should only need one call to
-- 
2.37.2

[PATCH 03/10] memfd_secret.2: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man2/memfd_secret.2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man2/memfd_secret.2 b/man2/memfd_secret.2
index d133ef1fb..e7a913361 100644
--- a/man2/memfd_secret.2
+++ b/man2/memfd_secret.2
@@ -193,7 +193,7 @@ therefore the system call is disabled by default and only available
 if the system administrator turned it on using
 "secretmem.enable=y" kernel parameter.
 .PP
-To prevent potiential data leaks of memory regions backed by
+To prevent potential data leaks of memory regions backed by
 .BR memfd_secret ()
 from a hybernation image,
 hybernation is prevented when there are active
-- 
2.37.2

[PATCH 04/10] clockid_t.3type: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man3type/clockid_t.3type | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man3type/clockid_t.3type b/man3type/clockid_t.3type
index 73ce55fb1..95ca1a56a 100644
--- a/man3type/clockid_t.3type
+++ b/man3type/clockid_t.3type
@@ -12,7 +12,7 @@ Standard C library
 .fi
 .SH DESCRIPTION
 Used for clock ID type in the clock and timer functions.
-It is be defined as an arithmetic type.
+It is defined as an arithmetic type.
 .SH STANDARDS
 POSIX.1-2001 and later.
 .SH NOTES
-- 
2.37.2

[PATCH 05/10] dev_t.3type: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man3type/dev_t.3type | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man3type/dev_t.3type b/man3type/dev_t.3type
index e86aca7dc..5676b6909 100644
--- a/man3type/dev_t.3type
+++ b/man3type/dev_t.3type
@@ -6,7 +6,7 @@
 .\"
 .TH DEV_T 3type 2021-11-02 Linux "Linux Programmer's Manual"
 .SH NAME
-dev_t \- devide ID
+dev_t \- device ID
 .SH LIBRARY
 Standard C library
 .RI ( libc )
-- 
2.37.2

[PATCH 06/10] itimerspec.3type: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man3type/itimerspec.3type | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man3type/itimerspec.3type b/man3type/itimerspec.3type
index 4ededad52..4ae0470cd 100644
--- a/man3type/itimerspec.3type
+++ b/man3type/itimerspec.3type
@@ -5,7 +5,7 @@
 .\"
 .TH itimerspec 3type 2022-08-01 Linux "Linux Programmer's Manual"
 .SH NAME
-timespec \- interval for a timer with nanosecond precission
+timespec \- interval for a timer with nanosecond precision
 .SH LIBRARY
 Standard C library
 .RI ( libc )
-- 
2.37.2

[PATCH 07/10] timespec.3type: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man3type/timespec.3type | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man3type/timespec.3type b/man3type/timespec.3type
index fb31357f8..52a55ea1d 100644
--- a/man3type/timespec.3type
+++ b/man3type/timespec.3type
@@ -53,7 +53,7 @@ In reality, the field ends up being defined as:
 .EE
 .in
 .PP
-This is a long-stansing and long-enshrined glibc bug
+This is a long-standing and long-enshrined glibc bug
 .UR https://sourceware.org/bugzilla/show_bug.cgi?id=16437
 .I #16437
 .UE ,
-- 
2.37.2

[PATCH 08/10] tm.3type: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man3type/tm.3type | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/man3type/tm.3type b/man3type/tm.3type
index 2cec54736..450bfbfe5 100644
--- a/man3type/tm.3type
+++ b/man3type/tm.3type
@@ -50,7 +50,7 @@ Feature Test Macro Requirements for glibc (see
 Describes time, broken down into distinct components.
 .PP
 .I tm_isdst
-describes wether daylight saving time is in effect at the time described.
+describes whether daylight saving time is in effect at the time described.
 The value is positive if daylight saving time is in effect,
 zero if it is not,
 and negative if the information is not available.
@@ -101,7 +101,7 @@ The
 field provides an alternative (with the opposite sign) for those systems.
 .PP
 .I tm_zone
-points to static storage and may be overriden on subsequent calls to
+points to static storage and may be overridden on subsequent calls to
 .BR localtime (3)
 and similar functions (however, this never happens under glibc).
 .SH SEE ALSO
-- 
2.37.2

[PATCH 09/10] fanotify.7: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man7/fanotify.7 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man7/fanotify.7 b/man7/fanotify.7
index 7edfea9a8..d6b816a5b 100644
--- a/man7/fanotify.7
+++ b/man7/fanotify.7
@@ -184,7 +184,7 @@ structure.
 Importantly,
 fanotify provides no guarantee around
 the ordering of information records
-when a notification group is intialized with a
+when a notification group is initialized with a
 stacked based configuration.
 Each information record has a nested structure of type
 .IR fanotify_event_info_header .
-- 
2.37.2

[PATCH 10/10] tcp.7: tfix

[Jakub Wilk]

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
 man7/tcp.7 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man7/tcp.7 b/man7/tcp.7
index a4c467fcd..61b55db66 100644
--- a/man7/tcp.7
+++ b/man7/tcp.7
@@ -1284,7 +1284,7 @@ to solicit a cookie.
 .IP
 If a cookie is available,
 .BR connect (2)
-would return 0 immediately but the SYN transmission is defered.
+would return 0 immediately but the SYN transmission is deferred.
 A subsequent
 .BR write (2)
 or
-- 
2.37.2

Re: [PATCH 01/10] fanotify_init.2: tfix

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1548 bytes --]

Hi Jakub,

On 8/19/22 21:08, Jakub Wilk wrote:
> Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
> ---
>   man2/fanotify_init.2 | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/man2/fanotify_init.2 b/man2/fanotify_init.2
> index 9eac6d2d7..262c505fa 100644
> --- a/man2/fanotify_init.2
> +++ b/man2/fanotify_init.2
> @@ -186,7 +186,7 @@ objects by file handles.
>   Note that without the flag
>   .BR FAN_REPORT_TARGET_FID ,
>   for the directory entry modification events,
> -there is an inforamtion record that identifies the modified directory
> +there is an information record that identifies the modified directory
>   and not the created/deleted/moved child object.
>   The use of
>   .B FAN_CLASS_CONTENT
> @@ -477,7 +477,7 @@ users may call
>   .BR fanotify_init ()
>   without the
>   .B CAP_SYS_ADMIN
> -capability to create and intialize an fanotify group with limited functionality.
> +capability to create and initialize an fanotify group with limited functionality.

should this be 'a fanotify' instead of 'an fanotify'?

BTW, I noticed you find a lot of typos.  I'm curious: do you find them 
when reading, or you run a tool that finds them?  If it's the latter, 
maybe you'd be interested in adding it to the Makefile, adding a lint-* 
target that we can run from time to time?

Cheers,

Alex

>   .TP
>   The limitations imposed on an event listener created by a user without the
>   .B CAP_SYS_ADMIN

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

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

Re: [PATCH 01/10] fanotify_init.2: tfix

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1362 bytes --]

Hi Jakub,

On 8/19/22 21:08, Jakub Wilk wrote:
> Signed-off-by: Jakub Wilk <jwilk@jwilk.net>

I applied the entire patch set, with the exception of 01/10 (this one), 
since I asked a question about it (but I like the patch).

Thanks!

Alex

> ---
>   man2/fanotify_init.2 | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/man2/fanotify_init.2 b/man2/fanotify_init.2
> index 9eac6d2d7..262c505fa 100644
> --- a/man2/fanotify_init.2
> +++ b/man2/fanotify_init.2
> @@ -186,7 +186,7 @@ objects by file handles.
>   Note that without the flag
>   .BR FAN_REPORT_TARGET_FID ,
>   for the directory entry modification events,
> -there is an inforamtion record that identifies the modified directory
> +there is an information record that identifies the modified directory
>   and not the created/deleted/moved child object.
>   The use of
>   .B FAN_CLASS_CONTENT
> @@ -477,7 +477,7 @@ users may call
>   .BR fanotify_init ()
>   without the
>   .B CAP_SYS_ADMIN
> -capability to create and intialize an fanotify group with limited functionality.
> +capability to create and initialize an fanotify group with limited functionality.
>   .TP
>   The limitations imposed on an event listener created by a user without the
>   .B CAP_SYS_ADMIN

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

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

Re: [PATCH 01/10] fanotify_init.2: tfix

[G. Branden Robinson]

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

Hi Alex,

At 2022-08-20T01:28:04+0200, Alejandro Colomar wrote:
> > -capability to create and intialize an fanotify group with limited functionality.
> > +capability to create and initialize an fanotify group with limited functionality.
> 
> should this be 'a fanotify' instead of 'an fanotify'?

Answering this requires people to document how the function/feature name
is supposed to be pronounced.  Use "an" if what follows is a vowel
sound.  Spelling is not a determining factor.

Unfortunately it is a tradition in Unix culture not to make
pronouciation of its lexicon of (historically) hermetically terse
identifier lexicon clear, so that the names of commands and functions
that are well known enough to come up in conversation at conventions can
be used a shibboleth to distinguish self-taught users and programmers
(and clueless sales personnel and would-be entrepreneurs) from
"authentic" Unix experts who underwent a proper apprenticeship, and
through a chain of masters, can trace their tutelage to a luminary at
the Bell Labs CSRC or UC Berkeley CSRG--someone with a name to be spoken
in hushed tones like "Ritchie" or "Joy".

Does "troff" have one syllable or two?  Does one refer to the text
editors as "ee-dee" and "vee-eye" or as if they were English diminutive
names "Ed" and "Vi"?  One set of choices will mark you as a person who
_might_ be worth conversing with; the other will get you a short look
down a long nose and the cold shoulder.  We've got gates to keep.

Both Unix and the Linux kernel, the latter particularly in its
development model, were levelling technologies.  They brought better OS
technology and programming environments to much larger groups of people
than had enjoyed them before.

But it is a sadly recurring theme of human history that as soon as some
levelling process occurs, a certain type of person promptly moves in to
restore a guild, caste, or other hierarchical social ordering that they
are more comfortable with.

If you can't get an authoritative answer from a principal author of the
fanotify API, I suggest reading the term as "eff-A-notify"; this will
then be implicitly documented by your choice of the article "an".  It
doesn't have anything to do with fans or the fourth degree of the major
scale, after all.

Regards,
Branden

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

Re: [PATCH 01/10] fanotify_init.2: tfix

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 3067 bytes --]

Hi Branden, Jakub,

On 8/21/22 07:28, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2022-08-20T01:28:04+0200, Alejandro Colomar wrote:
>>> -capability to create and intialize an fanotify group with limited functionality.
>>> +capability to create and initialize an fanotify group with limited functionality.
>>
>> should this be 'a fanotify' instead of 'an fanotify'?
> 
> Answering this requires people to document how the function/feature name
> is supposed to be pronounced.  Use "an" if what follows is a vowel
> sound.  Spelling is not a determining factor.
> 
> Unfortunately it is a tradition in Unix culture not to make
> pronouciation of its lexicon of (historically) hermetically terse
> identifier lexicon clear, so that the names of commands and functions
> that are well known enough to come up in conversation at conventions can
> be used a shibboleth to distinguish self-taught users and programmers
> (and clueless sales personnel and would-be entrepreneurs) from
> "authentic" Unix experts who underwent a proper apprenticeship, and
> through a chain of masters, can trace their tutelage to a luminary at
> the Bell Labs CSRC or UC Berkeley CSRG--someone with a name to be spoken
> in hushed tones like "Ritchie" or "Joy".
> 
> Does "troff" have one syllable or two?  Does one refer to the text
> editors as "ee-dee" and "vee-eye" or as if they were English diminutive
> names "Ed" and "Vi"?  One set of choices will mark you as a person who
> _might_ be worth conversing with; the other will get you a short look
> down a long nose and the cold shoulder.  We've got gates to keep.

You can guess the answers to those in my head ;)

> 
> Both Unix and the Linux kernel, the latter particularly in its
> development model, were levelling technologies.  They brought better OS
> technology and programming environments to much larger groups of people
> than had enjoyed them before.
> 
> But it is a sadly recurring theme of human history that as soon as some
> levelling process occurs, a certain type of person promptly moves in to
> restore a guild, caste, or other hierarchical social ordering that they
> are more comfortable with.
> 
> If you can't get an authoritative answer from a principal author of the
> fanotify API, I suggest reading the term as "eff-A-notify";

Ahh, makes sense now.  It hadn't occured to me that that was a possible 
pronounciation.  Anyway, it'll always be fa-notify in my head.  I'm 
waiting for sol-notify, which will be pronounced exactly as fanotify, 
but a tone higher :D

> this will
> then be implicitly documented by your choice of the article "an".

I was trying to come up with possible pronounciations that would have a 
vowel at the begining, but then I thought: no, who would pronounce this 
as f-a-notify?  It's too much work!  Heh!

>  It
> doesn't have anything to do with fans or the fourth degree of the major
> scale, after all.

Cheers,

Alex

P.S.: Patch applied.


-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

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

Re: [PATCH 01/10] fanotify_init.2: tfix

[Jakub Wilk]

* Alejandro Colomar <alx.manpages@gmail.com>, 2022-08-20 01:28:
>BTW, I noticed you find a lot of typos.  I'm curious: do you find them 
>when reading, or you run a tool that finds them?

I have two unconventional spellcheckers in my toolbox:

https://jwilk.net/software/mwic
https://jwilk.net/software/anorack

I usually run them on diffs, like this:

   $ git pull
   ...
   $ git diff @{1} | grep ^+ | mwic
   [wade through the jungle of false positives]

-- 
Jakub Wilk

Re: [PATCH 01/10] fanotify_init.2: tfix

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1641 bytes --]

Hi Jakub,

On 8/22/22 20:21, Jakub Wilk wrote:
> * Alejandro Colomar <alx.manpages@gmail.com>, 2022-08-20 01:28:
>> BTW, I noticed you find a lot of typos.  I'm curious: do you find them 
>> when reading, or you run a tool that finds them?
> 
> I have two unconventional spellcheckers in my toolbox:
> 
> https://jwilk.net/software/mwic
> https://jwilk.net/software/anorack
> 
> I usually run them on diffs, like this:
> 
>    $ git pull
>    ...
>    $ git diff @{1} | grep ^+ | mwic
>    [wade through the jungle of false positives]
> 

Interesting.  I run both through the entire repo.

anorack(1) seems to be reasonable, in that it runs in under 1 second, 
and only has 138 matches.  Many of them are false positives, but it's 
not unreasonable to go through them all.

$ time find man* -type f | xargs anorack | wc -l
138

real	0m0.971s
user	0m0.691s
sys	0m0.024s


I could add a `make lint-spell-anorack` target to run it from time to 
time.  Maybe you could special-case some of those false positives to 
make it even better?

mwick(1) seems to have an unreasonably huge number of false positives:

$ time find man* -type f | xargs  mwic | wc -l
139760

real	0m38.862s
user	0m38.653s
sys	0m0.224s

It seems it could get some help of understanding man(7) syntax to limit 
itself to text.  I'm definitely not adding this one for now.

Also, it would be nice if both of them had a way of reporting errors to 
make(1) through an EXIT STATUS, which could also be documented in their 
manual pages.


Cheers,

Alex

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

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