From nobody Fri Jun 19 22:45:11 2026 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ght393JLdz6h28Y for ; Fri, 19 Jun 2026 22:45:25 +0000 (UTC) (envelope-from ziaee@FreeBSD.org) Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [IPv6:2a0c:5a00:149::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ght390zCRz4KKh; Fri, 19 Jun 2026 22:45:25 +0000 (UTC) (envelope-from ziaee@FreeBSD.org) Authentication-Results: mx1.freebsd.org; none Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1wahxd-008jgr-Lk; Sat, 20 Jun 2026 00:45:17 +0200 Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1wahxX-0002Cr-Ts; Sat, 20 Jun 2026 00:45:12 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1wahxX-0008B3-Rs; Sat, 20 Jun 2026 00:45:11 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Received: from [Authenticated alias (960477)] by runbox.com with http (RMM6); Fri, 19 Jun 2026 22:45:11 GMT From: "Alexander Ziaee" To: "Dag-Erling Smørgrav" CC: "src-committers" , "dev-commits-src-all" , "dev-commits-src-main" , "Artem Bunichev" Subject: Re: git: b3dfd5d59c4a - main - rmdir.1: Document non-POSIX -v option Date: Fri, 19 Jun 2026 22:45:11 +0000 (UTC) X-RMM-Aliasid: 960477 X-Mailer: RMM6 In-Reply-To: <86zf0qtd1b.fsf@ltc.des.dev> Message-Id: X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO] X-Rspamd-Queue-Id: 4ght390zCRz4KKh X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 2026-06-19 17:50 -04:00 EDT, "Dag-Erling Sm=C3=B8rgrav" wrote: > Alexander Ziaee writes: >> Dag-Erling Sm=C3=B8rgrav writes: >> > Alexander Ziaee 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? >=20 > Right, so I thought we'd standardized on >=20 > 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 =E2=80=9Ca FreeBSD > extension=E2=80=9D or =E2=80=9Ca BSD extension=E2=80=9D or even =E2=80=9C= a GNU extension=E2=80=9D in cases where > we copied GNU's homework, and some just say =E2=80=9Can extension=E2=80= =9D. We should > clean that up. >=20 > There is precedent for =E2=80=9Can extension to that specification=E2=80= =9D but only in > pages where the previous sentence uses the word =E2=80=9Cspecification=E2= =80=9D. 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 somethi= ng 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: >=20 > The > .Nm > utility is expected to conform to the > .St -p1003.1-2008 > specification. >=20 > 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). >=20 > 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, Alex=