From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id UFs/KVB+MWOlowAAbAwnHQ (envelope-from ) for ; Mon, 26 Sep 2022 12:26:24 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 4JgcKVB+MWOuTAAAauVa8A (envelope-from ) for ; Mon, 26 Sep 2022 12:26:24 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3ECDCF73A for ; Mon, 26 Sep 2022 12:26:23 +0200 (CEST) Received: from localhost ([::1]:41658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oclJU-0008B8-Ol for larch@yhetil.org; Mon, 26 Sep 2022 06:26:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51296) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ockyg-0000JU-I7 for guix-devel@gnu.org; Mon, 26 Sep 2022 06:04:42 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:55786) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ockyd-0005Cc-To for guix-devel@gnu.org; Mon, 26 Sep 2022 06:04:42 -0400 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Mbdds1xG1z3wZs; Mon, 26 Sep 2022 12:04:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1664186674; bh=ompJtLWdK6CPVFCD4TZCVVd6VNRbVcc5BVwJxnsndMM=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=D/+SoNeC/nlP0UDGhXiTtVMs9xugoU8I0HykfeWNCkOX3j/HWiGVM3VbA7JiUEUdc bMnbqFfgVT9bQHbO0HCPV5su4eqyL+m9U9l/Xs74mvVYHj5NTdtoi9/NhCIdLztsxG fpwtsyNj/SCBj4YAkNtrel4s4eAJMb9UBkhki45Q= Message-ID: Subject: Re: What 'sh' should 'system' use? From: Liliana Marie Prikler To: Philip McGrath , guix Cc: Maxime Devos , Liliana Marie Prikler Date: Mon, 26 Sep 2022 12:04:32 +0200 In-Reply-To: References: <2284386.8hzESeGDPO@bastet> <3147250c1695e9ff0885cec9b2ba847a31071bb1.camel@ist.tugraz.at> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 MIME-Version: 1.0 X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 Received-SPF: none client-ip=129.27.2.202; envelope-from=liliana.prikler@ist.tugraz.at; helo=mailrelay.tugraz.at X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1664187984; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=ompJtLWdK6CPVFCD4TZCVVd6VNRbVcc5BVwJxnsndMM=; b=K5p6TmmS8OVWD2jXSGxE1awZzz4qrEDhaZZrP4kDaLEAW+QriCJHvm6oumj4epCOdGn6eT tvWgpjjzV7MCPomC/ERFqWZU9KlAKEQL2LQpAEE9eC2FjXcpG9ZmV85pgQnMnkeslK7Tpp cvAp1ee8EBLcCh2cxk8XXW1Js2Q7i6H8tS5cZmLKA3u4Ogvi9lGMEYeazJJsaRwwTCWqSy q9iCYSrYYdZzAEDkjCUkbI6TaCQf+JTRownIdhXveigxEX1I4jaBD1TBm7YLhe/PRcI5O0 ZdGXv2H9n0opTzGfQacj1jX3otiaW07uyFQWVmyMGH+yRqo3OCRthw7QkCMbLA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1664187984; a=rsa-sha256; cv=none; b=RAt9kqK2TLwv23XukfZWeGgkjzeCWR0R5M+YS5Xwy5p0juzyewHMs507b71rtLqvplqRVW hfKNrdP+TcKMrukmR643bWO//GK/EF0ZBfDY1UDNSKH38xvu9ltzwkyVLJVXx9WxUD1Ynf 9LmzCmm/6Qa69rV7McRZ//NDIyT9c3J5awO04XC1lY4UdBG+ViCQ95duAo4WamxL32+XRd YRoPACInvUZl+2MbPH4u+VIbhcsf11AYtZ33Lq8roHsAf3i8pEZ9XnjwFc7GpgMwS0/H6n 2px3vMVkkJ+KL6CUAlhpUkyFGLFA49l8MtWPktLLNOYlv2DkgmqBb25ZBzBAQA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b="D/+SoNeC"; dmarc=pass (policy=none) header.from=tugraz.at; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.04 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b="D/+SoNeC"; dmarc=pass (policy=none) header.from=tugraz.at; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3ECDCF73A X-Spam-Score: -1.04 X-Migadu-Scanner: scn1.migadu.com X-TUID: /6YYpLHmBWEE Hi, Am Montag, dem 26.09.2022 um 04:07 -0400 schrieb Philip McGrath: > Hi, >=20 > On 9/19/22 03:07, Liliana Marie Prikler wrote: > > Am Sonntag, dem 18.09.2022 um 20:13 -0400 schrieb Philip McGrath: > > > On the other hand, even Nix puts '/bin/sh' at its usual path: we > > > are really quite an outlier in this respect. (IIUC, Nix also has=20 > > > '/usr/bin/env', but no other utilities at FHS paths.) > > We are not.=C2=A0 We provide both /bin/sh and /usr/bin/env.=C2=A0 If yo= u're=20 > > talking about the build container then that's a much smaller=20 > > distinction. > >=20 >=20 > Yes, I'm talking about the build container. But for the build > container, programs/libraries that use "/bin/sh" would work > unmodified. I think there's limited value in having them work unmodified; see =E2=80=98patch-source-shebangs=E2=80=99. > > > More broadly, I now think it would be better in we embedded zero=20 > > > references to copies of Bash in libc. > > I don't think we can do that without breaking system. > >=20 >=20 > When "/bin/sh" is not available at runtime, I think libc's `system` > ought to return 127, and other `system`-like functions should raise > exceptions or whatever the idiomatic way is to signal failure. Of > course, we will presumably need to make "/bin/sh" available in many > more places, but don't think it's surprising for programs that need > to run shell commands to fail in the absence of a shell. Au contraire, I'd argue that people who use system will be the most surprised when it actually does fail. > > > However, giving every program using Glibc a hard dependency on=20 > > > Bash=E2=80=94and on a particular Bash executable=E2=80=94seems like a= much bigger > > > imposition. > > We're talking 1.7 MiB here.=C2=A0 Certainly a "big" imposition, but > > nothing in comparison to the things you need in the store for > > bootstrapping purposes.=C2=A0 Also note that bash-minimal, while only > > taking up 1.0 MiB for itself, requires both glibc and gcc:lib, > > which apart from creating a cycle does blow up its closure size > > quite a bit. > >=20 >=20 > I'm less concerned with the literal size than with the significance > of putting a specific shell so near the root of most dependency > graphs: I tried to give examples in my reply to Maxime, like creating > containers without a shell. What is this significance? From the examples you gave Maxime, I find it insignificant. > > >=20 > > It is therefore permissible for the system() function on such a > > system to implement the behavior specified by the ISO C standard as > > long as it is understood that the implementation does not conform > > to POSIX.1-2017 if system(NULL) returns zero. >=20 > I understand that to mean that `system(NULL)` returning zero > indicates that the program is not (currently) running in a POSIX.1- > 2017 environment. This test is severely broken. It fails to account for non-POSIX.1-2017 systems, that nevertheless return 1. >From the GNU coding standards [1]: > The GNU Project regards standards published by other organizations as > suggestions, not orders. We consider those standards, but we do not > =E2=80=9Cobey=E2=80=9D them. In developing a GNU program, you should impl= ement an > outside standard=E2=80=99s specifications when that makes the GNU system > better overall in an objective sense. When it doesn=E2=80=99t, you should= n=E2=80=99t. Here, conforming to POSIX makes sense: it improves portability at little cost. > Guix creates many environments that do not conform to POSIX.1-2017: > for example, any environment without `vi`. Here it doesn't. The convenience of vi is highly debatable. Cheers