From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 085E99A62; Mon, 25 May 2026 13:22:50 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id B31719A4B; Mon, 25 May 2026 13:22:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) by atuin.qyliss.net (Postfix) with ESMTPS id 505B89A4A for ; Mon, 25 May 2026 13:22:46 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id BEC0014000B4; Mon, 25 May 2026 09:22:44 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 25 May 2026 09:22:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1779715364; x=1779801764; bh=zjA4kkEJ3Z thx6pPlhVUM+Nccvq8W60zXO9NJlY59jM=; b=wlw2HnfDB6zG7KPF3mWPmOfKTO c/x2MSPSMuqhkJydkcXYzc6oUg8eMB95Nk9UAv17rqfRdlFiEzofNgf9njtmUZHf LeHftyRWqwWela9PQZsDnmBKRM7YaWibhy2h56MgYdZkJoTaa2UHMACRWdw9jBXM 3VbmHjrm2ncOhh9iZjzDpwKtGVFy2K5hITw2niROqn/Nt+tltKcf/3VYGY+NbSVg 4DT2Pe3aYNhhbksAK7oUZ6sFNFFIUYnEv7JwVEoBiZeDHL5p7TH+WRvAoCf6WAze Gn+qvQAQ/hiymFTUSNpbExRJy26tx4pF8rGL3t0Zy8X42TrI+aMgYSScyDzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1779715364; x=1779801764; bh=zjA4kkEJ3Zthx6pPlhVUM+Nccvq8W60zXO9 NJlY59jM=; b=NPSUZCzNw9wUuZcGAHNZbh7Alzbz8Xm/0cwocyGnYCubbVMhLAJ LGZL61J2D/UQ1XWG09pV+gkUbdiMA1WxPBpAY+wEAvhwkvKqNLoshioJcWqO/4SF IcYM5YCeTpjxKHT+DIW8Yu/+uJYmrVkqwPFd9M0dWgdhkVf9P6ANf33p5roveEo8 x2PLaIOu/vPb7xWkvy9ikKw3z4nm+Ho6/s0THWWY5uzrmtQ6+tydcYGjzvJV/iA3 YQGO3bgrI7p4iSccpzSM9KA/YY2POaSe37bjuGiTmaroNcaTz4aRUCU8b9c3DbbT WMc5jYz1VdzEd0q4eAJ3v8Ezq6/uovKA0BQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGl4XRNuGoT2YVESz1COgUT1qWi3JzVdUe9BKFVHy/co9MJLQRXgvmtFrNB+IA08D FV2aqzIr+Z/s81muC1SnM5+DkMNXbCjhadAcmKNJHKrQsX6Krg6eYWY3HvLAQFJpjlUSj4 sLlht+Dm7NZn01uZuOv6+w9dlDu/MIgl7Sv5oeOF8xqJi1QceAcqRGnqSBv0VFNSZAJanK xONf2/3MomliotwC0Bc1E6/xSKQei5XIpn8XIYMbIvOilIZhP6GwMgowe+lA/XOp7bAVTD MeBmpr/2elZ/NFMDkvcGv3oYrWrYS1DFJ9/ufBUjdR53F9TEA6iMHB6RdgtKzGrugpa9ef Lbj+cE8MuhOTb7S7hLOAorkZSpgwV+WTMHqs1ast4psrz89ldGFdYyJ0jLBXMdG95AoYLR FRnqa8mp4YzBNgADug1a9bHtvBcMfThIZXerVyxwWkNFHQA6WjCwoXSmzfz6ejZn3Xh5eS B2ztpBB4KCVNb8aUEkQN3zkqGjYqpL4O2x9P4AS3rSWVYPhJpAKbqCFJeNJE4ABfmAuwu2 UK9ICFXN5gna6yFmjOK8t/2VIdsmV+sYcEUi9UQOFzXI/7Cz91uNZ+m1axI43lE5GlWZsA Z5YY20uTgeqayluPYqFgIKzm644wTtHLUFFjFWZ5e4Ehw3usM0Z3zx8BO8fg X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 May 2026 09:22:44 -0400 (EDT) Received: by fw12.qyliss.net (Postfix, from userid 1000) id 0E99AB2733CD; Mon, 25 May 2026 15:22:43 +0200 (CEST) From: Alyssa Ross To: Valentin Gagarin Subject: Long vs. short options In-Reply-To: <87a4tqfflt.fsf@alyssa.is> References: <20260520222237.257773-1-valentin@gagarin.work> <878q9ar0ky.fsf@alyssa.is> <87a4tqfflt.fsf@alyssa.is> Date: Mon, 25 May 2026 15:22:40 +0200 Message-ID: <87fr3fzkrj.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: R3KFHALNDXVZRA5CDSXCCVX6BNYAN7UF X-Message-ID-Hash: R3KFHALNDXVZRA5CDSXCCVX6BNYAN7UF X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.9 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alyssa Ross writes: > Valentin Gagarin writes: > >> The reasons I wrote it out is that it's more obvious what it does=20 >> without looking up the documentation. As a project grows larger and so= =20 >> does the number of tools or options in use, the amount of rare things=20 >> one needs to "just know" tends to become unmanageable, and the time to=20 >> decompress a highly compressed representation goes up. >> >> This is, what I consider to be by now classic, advice, which I have=20 >> assumed to be tacit knowledge: >> https://changelog.com/posts/use-long-flags-when-scripting >> >> Discussion: >> - https://news.ycombinator.com/item?id=3D5164354 (2013) >> - https://news.ycombinator.com/item?id=3D24518682 (2020) >> >> In this particular case, nothing would tell me off the cuff what `-I` is= =20 >> supposed to mean for `grep`. It seems reasonable to be explicit here=20 >> and avoid the extra round of distraction for readers. This has even=20 >> more impact on people with less experience (overall or just with the=20 >> particular tools). >> >> No action required now, the change is merged and does its thing. But I= =20 >> suggest considering whether a note on the issue should be added to a=20 >> document about coding conventions. > > I think you're probably right and I'd be happy for the convention to be > changed and documented (but long single lines still avoided). I thought about this a bit more. I think there are three classes of scripts in Spectrum in regards to this, each with different considerations: =E2=80=A2 Bash code embedded into Nix files. Being in Nix files they'll al= ways be run in a consistent environment, so no problems with long options here. =E2=80=A2 execline code that's installed into the Spectrum system. As abov= e, but it's worth noting that these scripts mostly run execline/s6 executables, which do not provide any long options. We could still use long options for programs that have them, but might feel inconsistent (although it's also inconsistent when long options need to be passed to some program today). I think it probably makes sense to make the change here. =E2=80=A2 Scripts that are part of Spectrum's build system. These have alw= ays been written with the intention of being portable. In some cases we might publish code as part of Spectrum that others might want to build on or for some other systems. To facilitate reuse (and in the case of Make especially, also to try to avoid the pitfalls and complexity that come with the GNU extensions), I've discouraged use of non-standard features of utilities that might be part of an OS, like coreutils (or equivalent), or awk or Make. POSIX only standardizes short options, so for this category, I think it makes sense to stick to those for the portability advantages. We could further break this down into scripts that we expect to be reused and those we don't, but I think that would be a difficult distinction for people to make. Just my thoughts. :) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQGoGac7QfI+H5ZtFCZddwkt31pFQUCahRNIAAKCRCZddwkt31p FawJAQDEzOUlweIurMx+hZ4/O+D66axcqxOt608FK3FqoL7I7QD6AjLxTFfGX6Xk LJgc7B1ONk+AT9y+qtuVwtdR0WvT5QE= =IYwx -----END PGP SIGNATURE----- --=-=-=--