From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id GGUrKkYwBGOhEQEAbAwnHQ (envelope-from ) for ; Tue, 23 Aug 2022 03:41:26 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id uENIKkYwBGPScQAA9RJhRA (envelope-from ) for ; Tue, 23 Aug 2022 03:41:26 +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 AC66D93C2 for ; Tue, 23 Aug 2022 03:41:25 +0200 (CEST) Received: from localhost ([::1]:43462 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQIuy-000823-J4 for larch@yhetil.org; Mon, 22 Aug 2022 21:41:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49214) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQIud-00081t-11 for guix-patches@gnu.org; Mon, 22 Aug 2022 21:41:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52381) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQIuc-0002vP-OB for guix-patches@gnu.org; Mon, 22 Aug 2022 21:41:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oQIuc-00058J-8K for guix-patches@gnu.org; Mon, 22 Aug 2022 21:41:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#57050] [PATCH v2 04/13] gnu: Add Zuo. Resent-From: "Philip McGrath" Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 23 Aug 2022 01:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57050 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: "Maxime Devos" , "Liliana Marie Prikler" , 57050@debbugs.gnu.org Cc: Liliana Marie Prikler , Efraim Flashner , Thiago Jung Bauermann Received: via spool by 57050-submit@debbugs.gnu.org id=B57050.166121885919714 (code B ref 57050); Tue, 23 Aug 2022 01:41:02 +0000 Received: (at 57050) by debbugs.gnu.org; 23 Aug 2022 01:40:59 +0000 Received: from localhost ([127.0.0.1]:42130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQIuY-00057u-G7 for submit@debbugs.gnu.org; Mon, 22 Aug 2022 21:40:59 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:59743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQIuV-00057b-Vn for 57050@debbugs.gnu.org; Mon, 22 Aug 2022 21:40:56 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9863D5C00C2; Mon, 22 Aug 2022 21:40:50 -0400 (EDT) Received: from imap52 ([10.202.2.102]) by compute4.internal (MEProxy); Mon, 22 Aug 2022 21:40:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= philipmcgrath.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1661218850; x= 1661305250; bh=dXJvDFfjfP/wadm9kbaKpsnP6HPNu9QPUAf7xBiMjjM=; b=E I94zY4sNePLjmOvwWylDngciKGYUhDlJbZWBuQGGcMJsYKM74EOt2BH6OaaiY+aO +H+nYLpy5ZHVN7k2ohF/w2/KOVLRZn6S1XIC+F3kJ6UAAp5wi61+qyGbdFN3dFoW ihY5o3GqS8OpDjZPi1TFvHvSQr5jxhDfgWz05074u+VlLRYOrJijAMf+vuJMmjaC TGQzSFiF4dKSw281nBalhjceg9L6gZk6IfpJi2ORD3rMc+sOKX0O+BnOMtS8oWwX 2AXuSxWuxQe5cpR//ha7jmok0jJbGUZNL9odf8z5zG2uKIPMsRdakgbAsD23waqH JvbZyBCx+vGc47huTHwcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1661218850; x=1661305250; bh=dXJvDFfjfP/wadm9kbaKpsnP6HPN u9QPUAf7xBiMjjM=; b=EXiNuDO+yZh14EKrLrDHo5opXLAsSxf/fsRQ1goNgQgQ FAiOzYHLiLeRUGJ2G+Tr7rx2+YArLw/b4YG6ijztKt1LZd5fdh9mrFtqdQUAEK4m TGk+xVWEwOGFvwbCMBInm4cTIL3llDBtBXnfCS3lvEdaYqtnUxsBhpCdxtrvRimI xRtst3swQNCpXYgoOqO2Y0/nDnlC0/KqbhQStUAH7vyTuqqeyzEyFlEZne1ffOE5 LgVkPCvA18P7PO+7uxmhH6aB7azab+oKA06PCQvkBLnogvHeJYUgiDvngq99/pXi Rckhw7ayjqS72AJ57INC6w+JfQREAFrIAXuuXx6HhQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdeikedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfrfhh ihhlihhpucfotgfirhgrthhhfdcuoehphhhilhhiphesphhhihhlihhpmhgtghhrrghthh drtghomheqnecuggftrfgrthhtvghrnhepfeehhfdvffdvkefhjedvheeuffdtieejtefg jedtieehteffjeetteejjedthfetnecuffhomhgrihhnpegtphhprhgvfhgvrhgvnhgtvg drtghomhdpohhpvghnghhrohhuphdrohhrghdpghhnuhdrohhrghenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphhhilhhiphesphhhihhlih hpmhgtghhrrghthhdrtghomh X-ME-Proxy: Feedback-ID: i2b1146f3:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9AA6CC6008B; Mon, 22 Aug 2022 21:40:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a Mime-Version: 1.0 Message-Id: In-Reply-To: <923c0709-4fe9-5f02-06a1-196095f5199e@telenet.be> References: <285372112d70bcb4011d6c085592787df4f57d44.1660215295.git.philip@philipmcgrath.com> <4ae7af77-4ab6-4642-8c2f-854adec719c5@www.fastmail.com> <923c0709-4fe9-5f02-06a1-196095f5199e@telenet.be> Date: Mon, 22 Aug 2022 21:40:29 -0400 From: "Philip McGrath" Content-Type: text/plain X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" 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=1661218886; 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:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=dXJvDFfjfP/wadm9kbaKpsnP6HPNu9QPUAf7xBiMjjM=; b=XiPk+M4HhDUaaUK/p1BfbHpO/iMyCOYlzFp/hKzvlom28PLZIZRursu31OGNe5cy9ynGrB DemloVe7/J7diPjq4HMDA9x9iwebUgGhXPPC58YNlWi9h1swdeRz/rOqH62LBJgHdPaJCH u1A0h/adcec25BNBTXzPCOULMO1MNdU5rdGPiv6Gwo233Ab9cgoE4TC7PJDaiuZg3xUkf8 ZlyqYAAe3ZbgDcqI6Dx53I4qUh5rwfGMRC/3Sz75ixG7PZuU+i13Sh3KvblQ8kze+CKagu rxeO7WM25B+7sDQxaZGLB+Xp7/RZpS9rR13mU6SY1iOZ9fKJxARhD5PI0ZmZig== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1661218886; a=rsa-sha256; cv=none; b=iNW1vXzJN6DdcwJUcQuEkdvU136/tt+aSUvpzIX/oOXpf75FtjB85GK3nPWYreJBmaQgRt EMiejrh0wL+4tj3cMGuwXF1rSrPJbRBzywRAZ/jsaSA5cUiptXaPI/+8gaUJ0dTB24yHHn Odh4E/Bjpxoi2F2LqdO/6peNtAQ+PYTmfi5iuW1McwXRHHzb4CwxquTtVC0W3+M9dPXjV+ jP/OZz6XI7Ui9T6+A0Y2/4tANewE1V+pyskeSkqFnEPDijXHAVxqSFqcN+Eg6yMnm7g3hm WjlLtIgLAI3v4u3w8PYaEGmxU1BzPFCHMbCWpYEzOlC1a5Y1b9Ez/FbQxcYN6g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b="E I94zY4"; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=EXiNuDO+; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 5.10 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b="E I94zY4"; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=EXiNuDO+; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: AC66D93C2 X-Spam-Score: 5.10 X-Migadu-Scanner: scn1.migadu.com X-TUID: VAQ4Z9lR8p34 Hi, On Tue, Aug 16, 2022, at 10:47 AM, Maxime Devos wrote: > On 11-08-2022 16:00, Philip McGrath wrote: >>>> + #~`(,(string-append "CPPFLAGS=-DGUIX_RKTIO_BIN_SH=" >>>> + #$(file-append (this-package-input >>>> "bash-minimal") >>>> + "/bin/sh")) >>>> >>> As with chez-scheme, I do think using a Racket-agnostic macro name is >>> helpful here. >>> >> I'm planning to respond in the other thread about the possibility of a truly generic macro name, but I hope it doesn't need to become an issue blocking this patch series. For now, I'm not entirely sure what "Racket-agnostic" means; the bottom line for my is I think it would be absurdly awful to have to write, e.g. if cross-compiling using `distro-build` with the top-level Makefile: >> >> ./configure CPPFLAGS="GUIX_RKTIO_BIN_SH=/input/bin/sh GUIX_ZUO_BIN_SH=/input/bin/sh GUIX_CHEZ_BIN_SH=/input/bin/sh" CPPFLAGS_FOR_BUILD="GUIX_RKTIO_BIN_SH=/native-input/bin/sh GUIX_ZUO_BIN_SH=/native-input/bin/sh GUIX_CHEZ_BIN_SH=/native-input/bin/sh" > > Example: GUIX_SH=/inputs/bin/sh. > I will use GUIX_SH in v3 of this series. My concern with it originally was that it's generic enough that it might be used in other ways elsewhere in Guix, but, since I'm hoping it's only going to be a medium-term solution, it seems good enough, and I haven't heard any objections to it. > I haven't been following the discussion on the other patches, but didn't I give an example of something independent of the Racket component in use and even independent of Racket itself? See the suggestion of using the already existing _PATH_BSHELL from . It's even not Guix-specific, apparently it's a BSD-ism! > On Wed, Aug 10, 2022, at 7:46 AM, Maxime Devos wrote: > On 09-08-2022 23:58, Philip McGrath wrote: > >> On Tuesday, August 9, 2022 5:38:56 PM EDT ( wrote: >>> On Tue Aug 9, 2022 at 10:24 PM BST, Maxime Devos wrote: >>>> In the glibc headers, there's some (POSIX?) standard macro that points >>>> at "/gnu/store/.../bin/sh" (I don't recall the name), any reason we >>>> aren't using that macro? That would be Guix-independent. I'm not sure >>>> if a /gnu/store/... prefix is included, but if not, maybe we could try >>>> overriding it with -D...="/gnu/store/...", or failing that, add a >>>> post-unpack substitute* replacing [the macro name] -> >>>> "/gnu/store/.../bin/sh". >>> I believe you might be referring to , which defines _PATH_BSHELL. >>> >>> It's not standard C nor POSIX >>> though. >>> >>> -- ( > > Looking at the "paths.h" header, it appears to be a BSDism. Not really > standard but still better than a Guix-ism. > >> I'd love to be wrong, but I also can't find such a macro. In the glibc source >> tree, "stdlib/system.c" defines a stub implementation that always fails with >> ENOSYS, and "sysdeps/posix/system.c" contains: >> >> #define SHELL_PATH "/bin/sh" /* Path of the shell. */ >> #define SHELL_NAME "sh" /* Name to give it. */ >> >> Concretely, I think Guix's glibc currently uses /bin/sh dynamically: in my >> Chez example above, if you replace `process` with `system` (which uses libc's >> `system`), the result is always "/bin/sh\n". > > If so, that's a bug. I do not know what result you are referring to. (Disregard this part; I think I was thinking about some other way I had tried things.) > > Anyway, the Guix package definition of glibc substitutes _PATH_BSHELL > and SHELL_PATH, so unless there's a bug, it doesn't depend on /bin/sh. > I have been looking further into options for addressing this upstream. First of all, I have found that there *is* another Unix-like system where "/bin/sh" doesn't exist: on Android, the POSIX shell is usually at "/system/bin/sh". Also, at least on some versions, _PATH_BSHELL isn't a compile-time constant. It is: #define _PATH_BSHELL __bionic_get_shell_path() (There are also systems where "/bin/sh" is some non-POSIX shell and the POSIX shell is at "/usr/xpg4/bin/sh". If changing this upstream, Racket may need to decide whether POSIX compatibility or historical compatibility is more important there.) I've found that there does seem to be a POSIX recommendation for finding "sh". The POSIX spec for `system` says, under "Application Usage", "There is no defined way for an application to find the specific path for the shell. However, confstr() can provide a value for PATH that is guaranteed to find the sh utility." Similarly, says that "applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in." Most emphatically, says in the normative "Description": > > If the implementation supports the POSIX shell option, the string stored in buf after a call to: > > confstr(_CS_PATH, buf, sizeof(buf)) > > can be used as a value of the PATH environment variable that accesses all of the standard utilities of POSIX.1-2017, that are provided in a manner accessible via the exec family of functions, if the return value is less than or equal to sizeof(buf). > However, apparently using `confstr` with `_CS_PATH` does not give a useful result in Guix build environments. Try building the following package with `guix build -f`: I've put the interesting log output in the description. In particular, note that *both* bash-minimal and bash-static are present! --8<---------------cut here---------------start------------->8--- (use-modules (guix build-system gnu) (guix gexp) ((guix licenses) #:prefix license:) (guix packages)) (define src (plain-file "demo.c" "#include #include #include #include int main(int argc, char *argv[]) { puts(_PATH_BSHELL); size_t buf_len = confstr(_CS_PATH, NULL, 0); char* buf = malloc(buf_len); if (NULL == buf) { return 1; }; confstr(_CS_PATH, buf, buf_len); puts(buf); fflush(stdout); int status = system(\"echo $BASH\"); fflush(stdout); printf(\"status: %i\\n\", status); return 0; } ")) (package (name "libc-system-demo") (version "0") (source src) (build-system gnu-build-system) (arguments (list #:phases #~(modify-phases %standard-phases (delete 'configure) (replace 'build (lambda args (invoke "gcc" "-o" "demo" #$src))) (replace 'check (lambda args (invoke "./demo"))) (replace 'install (lambda args (install-file "demo" (string-append #$output "/bin"))))))) (home-page "https://issues.guix.gnu.org/57050") (synopsis "Some 'sh'-related values from glibc") (description "starting phase `check' /gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8/bin/sh /bin:/usr/bin /gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh status: 0 phase `check' succeeded after 0.0 seconds") (license license:cc0)) --8<---------------cut here---------------end--------------->8--- AFAICT, Glibc's `confstr` implementation for `_CS_PATH` doesn't have any mechanism for configuring the search path; it simply uses the compile-time version, `CS_PATH`, which is: #define CS_PATH "/bin:/usr/bin" More generally, it seems questionable for our glibc to retain a store reference to Bash (let alone two). Wouldn't that prevent creating containers or packs without a shell present? After I've sent a v3 of this series, I plan to raise these questions on the guix-devel list. Then, once I have a sense of whether Guix would like to support `confstr` with `_CS_PATH` as a way of finding the shell, I'll propose some changes to Racket upstream. -Philip