From: "Thaddeus H. Black" <thb@debian.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: linux-man@vger.kernel.org,
Alejandro Colomar <alx.manpages@gmail.com>,
"G. Branden Robinson" <g.branden.robinson@gmail.com>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [PATCH v3] filename.7: new manual page
Date: Tue, 19 Oct 2021 11:05:22 +0000 [thread overview]
Message-ID: <YW6mcn0uMW3FWUu6@b-tk.org> (raw)
In-Reply-To: <87fssxgzt8.fsf@oldenburg.str.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
On Tue, Oct 19, 2021 at 10:54:11AM +0200, Florian Weimer wrote:
> Maybe add: “A pathname contains zero or more filenames.”
Okay.
> What does this mean? I think only byte 0x2f is reserved. The UTF-8
> comment is misleading. A historic/overlong encoding of / in multiple
> UTF-8 bytes is *not* reserved.
I had not known that UTF-8 had an alternate encoding for any ASCII
character. Does it indeed have an alternate encoding? If so, where
can I learn more?
The new filename(7) manual page wishes to be correct but, otherwise,
would like to inflict upon the reader as little difficult technical
prose as it can. The page wants to remain readable. In this light, can
you advise me how the page should speak to your point?
> This conflicts with the presentation of / as a separator in pathnames, I
> think: The pathname "/usr/" contains two empty filenames.
I had not thought of that. Good point.
Thus, the empty filename is not forbidden but rather is reserved.
> > +No filename may exceed\~255 bytes in length,
> > +or\~256 bytes after counting the terminating null byte.
>
> This is not correct for Linux. Despite the definition of NAME_MAX,
> filenames can be longer than 255 bytes. NTFS and CIFS have a limit of
> 255 UTF-16 characters, which translates to about 768 bytes in the UTF-8
> encoding used by Linux.
I see.
Your feedback is helpful and appreciated (especially since you are the
first Fedora-class user to return a review).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-10-19 11:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-17 23:07 [PATCH v2] filename.7: new manual page Thaddeus H. Black
2021-10-18 16:25 ` Thaddeus H. Black
2021-10-18 16:33 ` [PATCH v3] " Thaddeus H. Black
2021-10-19 8:54 ` Florian Weimer
2021-10-19 11:05 ` Thaddeus H. Black [this message]
2021-10-19 13:55 ` Alejandro Colomar (man-pages)
2021-10-20 8:12 ` Florian Weimer
2021-10-21 12:18 ` Thaddeus H. Black
2021-10-19 13:38 ` Alejandro Colomar (man-pages)
2021-11-07 14:36 ` Thaddeus H. Black
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=YW6mcn0uMW3FWUu6@b-tk.org \
--to=thb@debian.org \
--cc=alx.manpages@gmail.com \
--cc=fweimer@redhat.com \
--cc=g.branden.robinson@gmail.com \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
/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