This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FYI: new openat-like function: mkdirat


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]