Date: Fri, 19 Jun 2026 22:45:11 +0000 (UTC) From: "Alexander Ziaee" <ziaee@FreeBSD.org> To: "Dag-Erling Smørgrav" <des@FreeBSD.org> Cc: "src-committers" <src-committers@FreeBSD.org>, "dev-commits-src-all" <dev-commits-src-all@FreeBSD.org>, "dev-commits-src-main" <dev-commits-src-main@FreeBSD.org>, "Artem Bunichev" <tembun@bk.ru> Subject: Re: git: b3dfd5d59c4a - main - rmdir.1: Document non-POSIX -v option Message-ID: <E1wahxX-0008B3-Rs@rmmprod05.runbox> In-Reply-To: <86zf0qtd1b.fsf@ltc.des.dev>
index | next in thread | previous in thread | raw e-mail
On 2026-06-19 17:50 -04:00 EDT, "Dag-Erling Smørgrav" <des@FreeBSD.org> wrote: > Alexander Ziaee <ziaee@FreeBSD.org> writes: >> Dag-Erling Smørgrav <des@FreeBSD.org> writes: >> > Alexander Ziaee <ziaee@FreeBSD.org> writes: >> > > +.Pp >> > > +The >> > > +.Fl v >> > > +option is an extension to that specification. >> > This is not the wording we normally use for these cases. >> We use in in rm(1), but we do not have a style guide and I am not >> aware of a consistent pattern. What would you prefer? > > Right, so I thought we'd standardized on > > The > .Fl v > option is a non-standard extension. Oh, I forgot about that. > but it's actually more varied than that, some pages say “a FreeBSD > extension” or “a BSD extension” or even “a GNU extension” in cases where > we copied GNU's homework, and some just say “an extension”. We should > clean that up. > > There is precedent for “an extension to that specification” but only in > pages where the previous sentence uses the word “specification”. I > would prefer not standardizing on a wording that relies on external > context. Okay, let's put this in mdoc(7) so I don't forget again and we have something to point to. To that end I have proposed the following revision: https://reviews.freebsd.org/D57690 > Furthermore, rmdir(1) does not follow the standard pattern, so maybe we > should start by fixing that: > > The > .Nm > utility is expected to conform to the > .St -p1003.1-2008 > specification. > > That's not the latest version of the standard, but we've made no effort > to update our codebase for 1003.1-2024, so it's the most recent one we > can plausibly claim conformance to (although in this particular case the > standard hasn't changed so we can probably go ahead with 1003.1-2024). > > Finally, the SEE ALSO section should reference rmdir(2). The proposed changed LGTM, feel free to commit (either 2008 or 2024) with `Reviewed by: ziaee`. Best, Alexhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1wahxX-0008B3-Rs>