[Top][All Lists]
[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.