From: bokr@bokr.com
To: Maxime Devos <maximedevos@telenet.be>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
"Chris Marusich" <cmmarusich@gmail.com>,
53355@debbugs.gnu.org, 51466@debbugs.gnu.org
Subject: bug#51466: bug#53355: guix shell --check: confusing error message
Date: Sat, 25 Jun 2022 22:06:46 +0200 [thread overview]
Message-ID: <20220625200646.GA8075@LionPure> (raw)
In-Reply-To: <bf5b3b83c03de0c5056255ea60a3d0b4f8036478.camel@telenet.be>
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:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48563>)
>
> 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
next prev parent reply other threads:[~2022-06-25 20:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-19 3:29 bug#53355: guix shell --check: confusing error message Chris Marusich
2022-01-24 14:35 ` Ludovic Courtès
2022-01-25 0:55 ` Chris Marusich
2022-01-25 13:39 ` Ludovic Courtès
2022-02-02 7:49 ` bug#51466: " Chris Marusich
2022-02-08 9:26 ` Ludovic Courtès
2022-02-13 23:17 ` Chris Marusich
2022-02-14 9:47 ` Ludovic Courtès
2022-03-08 19:07 ` Ludovic Courtès
2022-05-20 21:37 ` Ludovic Courtès
2022-05-24 4:42 ` Chris Marusich
2022-06-13 10:03 ` Ludovic Courtès
2022-06-19 20:40 ` Chris Marusich
2022-06-20 7:34 ` bug#51466: " Ludovic Courtès
2022-06-20 10:12 ` bug#53355: " bokr
2022-06-20 17:56 ` Bengt Richter
2022-06-20 23:27 ` bug#51466: " Bengt Richter
2022-06-21 4:00 ` Thiago Jung Bauermann via Bug reports for GNU Guix
2022-06-25 9:07 ` Chris Marusich
2022-06-25 9:37 ` bug#53355: bug#51466: " Maxime Devos
2022-06-25 16:52 ` Chris Marusich
2022-06-25 17:40 ` Maxime Devos
2022-06-25 20:06 ` bokr [this message]
2022-06-25 21:04 ` bug#51466: " Maxime Devos
2022-06-26 10:33 ` Josselin Poiret via Bug reports for GNU Guix
2022-06-26 13:07 ` Maxime Devos
2022-06-26 19:45 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2022-06-27 10:17 ` bug#51466: " Ludovic Courtès
2022-06-27 10:34 ` bug#53355: " Maxime Devos
2022-06-28 7:45 ` Ludovic Courtès
2022-06-28 10:38 ` Maxime Devos
2022-06-28 16:57 ` bug#53355: " paren--- via Bug reports for GNU Guix
2022-06-28 17:31 ` bug#51466: " Maxime Devos
2022-07-04 8:11 ` Ludovic Courtès
2022-06-27 11:23 ` bokr
2022-06-27 14:22 ` bug#51466: bug#53355: " Bengt Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220625200646.GA8075@LionPure \
--to=bokr@bokr.com \
--cc=51466@debbugs.gnu.org \
--cc=53355@debbugs.gnu.org \
--cc=cmmarusich@gmail.com \
--cc=ludo@gnu.org \
--cc=maximedevos@telenet.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).