bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: new openat-like function: mkdirat


From: Jim Meyering
Subject: Re: FYI: new openat-like function: mkdirat
Date: Wed, 30 Nov 2005 22:08:52 +0100

Roland McGrath <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]