linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: alx.manpages@gmail.com, Jakub Wilk <jwilk@jwilk.net>
Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org
Subject: Re: [PATCH] pipe.7: tfix
Date: Mon, 18 Jan 2021 16:40:52 +0100	[thread overview]
Message-ID: <345ab74a-c8fa-b5ea-89b6-73b7001e4fb7@gmail.com> (raw)
In-Reply-To: <3bfc7e28-9663-40d0-a4b2-5ce9cefca01b@gmail.com>

Hi Alex (and Jakub)

On 1/18/21 4:19 PM, Alejandro Colomar (mailing lists; readonly) wrote:
> On 1/18/21 10:17 AM, Jakub Wilk wrote:
>> Escape hyphens.
> 
> Hi Jakub,
> 
> Would you mind adding not only 'what',
> but also (and especially) 'why' is does it?
> I mean, 20 years from now we might wonder why we escaped hyphens.
>
> Adding for example the following to the commit message might help:
> 
> [
> $ man 7 man-pages 2>/dev/null \
>   |sed -n '/Generating optimal glyphs/,/\\-/p';
>    Generating optimal glyphs
>        Where a real minus character is required (e.g., for numbers
>        such as -1, for man page cross references such as utf-8(7),
>        or when writing options that have a leading dash,  such  as
>        in ls -l), use the following form in the man page source:
> 
>            \-
> ]
> 
> I'm also wondering... are there any other places where this patch would
> also be needed?

Well, it is documented in our man-pages(7). I think just an
"As per man-pages(7), ..." would suffice. But even without
it, I would not worry too much.

I think it's great when you add stuff like this little script in 
your commit messages, but I don't want to impose that burden on
others.

Thanks,

Michael



>> Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
>> ---
>>  man7/pipe.7 | 18 +++++++++---------
>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/man7/pipe.7 b/man7/pipe.7
>> index 21c8fa79b..c3210320c 100644
>> --- a/man7/pipe.7
>> +++ b/man7/pipe.7
>> @@ -163,7 +163,7 @@ but is provided on many implementations.
>>  .SS /proc files
>>  On Linux, the following files control how much memory can be used for pipes:
>>  .TP
>> -.IR /proc/sys/fs/pipe-max-pages " (only in Linux 2.6.34)"
>> +.IR /proc/sys/fs/pipe\-max\-pages " (only in Linux 2.6.34)"
>>  .\" commit b492e95be0ae672922f4734acf3f5d35c30be948
>>  An upper limit, in pages, on the capacity that an unprivileged user
>>  (one without the
>> @@ -175,9 +175,9 @@ The default value for this limit is 16 times the default pipe capacity
>>  (see above); the lower limit is two pages.
>>  .IP
>>  This interface was removed in Linux 2.6.35, in favor of
>> -.IR /proc/sys/fs/pipe-max-size .
>> +.IR /proc/sys/fs/pipe\-max\-size .
>>  .TP
>> -.IR /proc/sys/fs/pipe-max-size " (since Linux 2.6.35)"
>> +.IR /proc/sys/fs/pipe\-max\-size " (since Linux 2.6.35)"
>>  .\" commit ff9da691c0498ff81fdd014e7a0731dab2337dac
>>  The maximum size (in bytes) of individual pipes that can be set
>>  .\" This limit is not checked on pipe creation, where the capacity is
>> @@ -202,7 +202,7 @@ Since Linux 4.9,
>>  the value on this file also acts as a ceiling on the default capacity
>>  of a new pipe or newly opened FIFO.
>>  .TP
>> -.IR /proc/sys/fs/pipe-user-pages-hard " (since Linux 4.5)"
>> +.IR /proc/sys/fs/pipe\-user\-pages\-hard " (since Linux 4.5)"
>>  .\" commit 759c01142a5d0f364a462346168a56de28a80f52
>>  The hard limit on the total size (in pages) of all pipes created or set by
>>  a single unprivileged user (i.e., one with neither the
>> @@ -220,7 +220,7 @@ no hard limit is applied.
>>  .\" The default was chosen to avoid breaking existing applications that
>>  .\" make intensive use of pipes (e.g., for splicing).
>>  .TP
>> -.IR /proc/sys/fs/pipe-user-pages-soft " (since Linux 4.5)"
>> +.IR /proc/sys/fs/pipe\-user\-pages\-soft " (since Linux 4.5)"
>>  .\" commit 759c01142a5d0f364a462346168a56de28a80f52
>>  The soft limit on the total size (in pages) of all pipes created or set by
>>  a single unprivileged user (i.e., one with neither the
>> @@ -238,9 +238,9 @@ The default value for this file is 16384,
>>  which permits creating up to 1024 pipes with the default capacity.
>>  .PP
>>  Before Linux 4.9, some bugs affected the handling of the
>> -.IR pipe-user-pages-soft
>> +.IR pipe\-user\-pages\-soft
>>  and
>> -.IR pipe-user-pages-hard
>> +.IR pipe\-user\-pages\-hard
>>  limits; see BUGS.
>>  .\"
>>  .SS PIPE_BUF
>> @@ -342,9 +342,9 @@ Portable applications should avoid reliance on
>>  bidirectional pipe semantics.
>>  .SS BUGS
>>  Before Linux 4.9, some bugs affected the handling of the
>> -.IR pipe-user-pages-soft
>> +.IR pipe\-user\-pages\-soft
>>  and
>> -.IR pipe-user-pages-hard
>> +.IR pipe\-user\-pages\-hard
>>  limits when using the
>>  .BR fcntl (2)
>>  .BR F_SETPIPE_SZ
>>
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

  reply	other threads:[~2021-01-18 15:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18  9:17 [PATCH] pipe.7: tfix Jakub Wilk
2021-01-18 15:19 ` Alejandro Colomar (mailing lists; readonly)
2021-01-18 15:40   ` Michael Kerrisk (man-pages) [this message]
2021-01-18 15:41 ` Michael Kerrisk (man-pages)

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=345ab74a-c8fa-b5ea-89b6-73b7001e4fb7@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=jwilk@jwilk.net \
    --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;
as well as URLs for NNTP newsgroup(s).