From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 25 16:07:15 2022 Received: (at 53355) by debbugs.gnu.org; 25 Jun 2022 20:07:15 +0000 Received: from localhost ([127.0.0.1]:46249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5C3m-0002Va-U5 for submit@debbugs.gnu.org; Sat, 25 Jun 2022 16:07:15 -0400 Received: from mailout.easymail.ca ([64.68.200.34]:52444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5C3h-0002VE-OS; Sat, 25 Jun 2022 16:07:13 -0400 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 2CAF8E21CA; Sat, 25 Jun 2022 20:07:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1656187624; bh=v/ZCgy20FdCTzk2Lawp4bN+em01WJ0n6GBjAjJ1JbCo=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=itH1Gz1WFPmIiTUmuUwyRLr1XqFrZdLi9IhKM6fZzu0f8eh+3b0CliXPfH0iVXJMt IH6J/tGZTPy7UXu64lMi/9y18KktEKIPapjxbvMGTHJSyrxIOwYYUdPkdMm1a0uuL0 HfIk4TFic1TDtrV+DYcMpozlBWEkm+ihlVMJcr9MpfdFd6B6nsmHTiQW9k84gS77ix sqZCpFtETLRUZbLnSgI5TC9e0nc/QGaytPADRtcoUflwYLN9FXNmG3EI7HSK9nZk4D OUOC5PHfDu3Dyz9jILSx1CMgB1UbgQnYNEXUwS1dhorIGMnx3S7X70mbi3+k9uVggy x9OFXIsx9Su/Q== X-Virus-Scanned: Debian amavisd-new at emo08-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo08-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2goac5yBtaQS; Sat, 25 Jun 2022 20:07:03 +0000 (UTC) Received: from localhost (m90-129-195-180.cust.tele2.se [90.129.195.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 3DF84E21C8; Sat, 25 Jun 2022 20:07:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1656187623; bh=v/ZCgy20FdCTzk2Lawp4bN+em01WJ0n6GBjAjJ1JbCo=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=aZlxro+hIVZFwOO2fGShjcyBZ5qagARZdbfXP5ERgxkHg6lLk5NYAUDQDkGdMzdsM e/QzkqFS/Bj9CS4ZnqVA8VlwTBSzaOAvRsYhj3SCAZGxlGmlmpSJobk8/BYtw2fI6n E24v6SALVUc/7Kex8tv16qMsjTQZPTI1TknEIakt5YDWE4+brbFfJR1k1q+5LJmKW9 PjHNnkCFhUlo9wGsyohQmfN/rCrF4NlIl/gMxOuMNEGg9Ayk77+ex9tPJ1oiiyikJF fPvMbSnZwq4FXawXkMV61H3twL2MJLPNMaYG1oZJUKKQYIwkI5TOTftbVGF8E5Q+23 gHaB/1SoOJcoA== From: bokr@bokr.com Date: Sat, 25 Jun 2022 22:06:46 +0200 To: Maxime Devos Subject: Re: bug#53355: guix shell --check: confusing error message Message-ID: <20220625200646.GA8075@LionPure> References: <87h79slysd.fsf@gnu.org> <87sft13dyv.fsf@gmail.com> <874k59d802.fsf@gnu.org> <87wnhy2w73.fsf_-_@gmail.com> <878rudzsmv.fsf@gnu.org> <87sfozzglf.fsf_-_@gmail.com> <875ykpdsbd.fsf_-_@gmail.com> <0b1765dfff5401fa06ee25779b7f173230bf4ea4.camel@telenet.be> <87y1xkwur9.fsf_-_@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53355 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , Chris Marusich , 53355@debbugs.gnu.org, 51466@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On +2022-06-25 19:40:48 +0200, Maxime Devos wrote: > Chris Marusich schreef op za 25-06-2022 om 09:52 [-0700]: > > Yes, I agree those are good reasons to avoid a temporary file if we > > can. > > To that end, do you know if we can somehow force Guile to use a > > specific > > file descriptor for the pipe?  In the patch I wrote earlier, which > > uses > > redirection, the problem was that I could not control Guile's choice > > of > > file descriptors.  Guile chose file descriptor 19 for one end of the > > pipe, and I don't know how to make it use anything else.  If we can > > arrange for Guile to consistently use file descriptor 7, for example, > > then probably it would work in all the shell I've tested. > > > > I wonder if maybe I can just duplicate the file descriptor?  I don't > > know; if for example Guile reserves all the file descriptors below 10 > > for other uses, it might be hard. > > > > Have a look at ‘(guile)Ports and File Descriptors’. It has lots of > procedures for duplicating and renumbering. That's fragile though, you > might accidentally overwrite an fd that's being used for something > else. > > (Normally move->fdes would prevent overwriting things by moving pre- > existing fds out of the way, adjusting ports automatically, but move- > >fdes doesn't know (yet) about the pipe that Guile uses for > finalisation, see maybe: > ) > > I think it would be best to patch the dash appropriately (though fixing > move->fdes would be nice too). > > Greetings, > Maximee. Could this help?: (from man 2 openat (scroll down a fair bit): -8<---------------cut here---------------start------------->8--- There are two main use cases for O_TMPFILE: * Improved tmpfile(3) functionality: race-free creation of temporary files that (1) are automatically deleted when closed; (2) can never be reached via any pathname; (3) are not subject to symlink at‐ tacks; and (4) do not require the caller to devise unique names. * Creating a file that is initially invisible, which is then populated with data and adjusted to have appropriate filesystem attributes (fchown(2), fchmod(2), fsetxattr(2), etc.) before being atomi‐ cally linked into the filesystem in a fully formed state (using linkat(2) as described above). O_TMPFILE requires support by the underlying filesystem; only a subset of Linux filesystems provide that support. In the initial implementation, support was provided in the ext2, ext3, ext4, UDF, Minix, and shmem filesystems. Support for other filesystems has subsequently been added as follows: XFS (Linux 3.15); Btrfs (Linux 3.16); F2FS (Linux 3.16); and ubifs (Linux 4.9) --8<---------------cut here---------------end--------------->8--- BTW, IIRC, this can be used to create an invisible file that can be mmap-ed, and the mmap will persist when you delete the file. Which then can be used as an anonymous buffer passed to wayland, along with metadate saying what the buffer contains, e.g. different kinds of rgb or rgba permutations and encodings, (or anything, which you can tell wayland just to keep track of for you. You need a directory for openat, so probably XDG_RUNTIME_DIR=/run/user/1000 is suitable if it exists. Worked in my case. HTH -- Regards, Bengt Richter