This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: FYI: new openat-like function: mkdirat
- From: Jim Meyering <jim at meyering dot net>
- To: Roland McGrath <roland at redhat dot com>
- Cc: bug-gnulib at gnu dot org, libc-alpha at sources dot redhat dot com, Ulrich Drepper <drepper at redhat dot com>
- Date: Wed, 30 Nov 2005 22:08:52 +0100
- Subject: Re: FYI: new openat-like function: mkdirat
- References: <20051130205642.264161809B9@magilla.sf.frob.com>
Roland McGrath <roland@redhat.com> wrote:
>> cp, cpio, mv, and tar currently use mkfifo and mknod,
>> so you might want to add mkfifoat and mknodat to the list, too.
>
> I suppose, though those are used by so few programs it is a bit more
> questionable.
Either way, it doesn't change much, since on Linux an application
can always use mkfifo ("/proc/self/fd/N/foobar", ... to work around
the absence of mkfifoat.
>> I haven't looked too closely at find, but its -execdir predicate
>> makes me think having exec*at functions would be useful, too.
>> But can glibc provide those without kernel support?
>
> We can certainly implement any such calls easily on the Hurd. :-)
> On Linux, off hand I think that the /proc/self/fd/N/foobar method works
> across the board, though I am not really sure.
I've just realized there is some ambiguity in my suggesting `exec*at'.
Unlike all of the other functions we've considered, these
have two things that may be fd-relative: the first argument
and the working directory. I was considering only the working
directory part, which doesn't fit the /proc/self/fd/N/foobar mold.
Find's -execdir predicate execs the specified command from its
current (varies through the traversal) directory, using directory
entry names as arguments.
So I guess the exec*at business would ultimately be more complicated,
with two file descriptor parameters: one identifying the working
directory, and another by which to interpret the first parameter
if it's a relative file name.