Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> You're talking about exec. If you're going to use execve anyway,
> there's no way you need your old initial working directory back, is
> there?
Right.
As James pointed out, the forked child can simply call
fchdir just before execvp, just as find alr
On Wed, Nov 30, 2005 at 09:53:53PM +0100, Jim Meyering wrote:
> Roland McGrath <[EMAIL PROTECTED]> wrote:
> > I think that the Solaris *at functions were really primarily intended for
> > use with O_XATTR to get at "file attribute" magic pseudo-directories rather
> > than to optimize use of normal
On Wed, Nov 30, 2005 at 11:34:40PM +0100, Jim Meyering wrote:
> Roland McGrath <[EMAIL PROTECTED]> wrote:
> >> 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 interpre
On Wed, Nov 30, 2005 at 09:53:53PM +0100, Jim Meyering wrote:
> I haven't looked too closely at find, but its -execdir predicate
> makes me think having exec*at functions would be useful, too.
Only slightly. POSIX requires that -exec should happen with the
working directory the same as it was wh
> 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.
It seems adequate to just use chdir/fchdir for changing cwd,
> 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.
> I haven't looked too closely at find, but its -execdir predicate
> makes me think having e
I think that the Solaris *at functions were really primarily intended for
use with O_XATTR to get at "file attribute" magic pseudo-directories rather
than to optimize use of normal directories and files. Probably mkdirat
doesn't make sense in Solaris attribute pseudo-directories. But mkdirat is
a
Roland McGrath <[EMAIL PROTECTED]> wrote:
>> 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.
>
> It seems ad
Roland McGrath <[EMAIL PROTECTED]> 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 o
Roland McGrath <[EMAIL PROTECTED]> wrote:
> I think that the Solaris *at functions were really primarily intended for
> use with O_XATTR to get at "file attribute" magic pseudo-directories rather
> than to optimize use of normal directories and files. Probably mkdirat
> doesn't make sense in Solar
Thinking about how to make thread-safe the directory-creating parts
of cp -r, mv, tar, cpio, and even mkdir -p (i.e., don't change
the initial working directory), while remaining efficient even for
deep hierarchies, I realized that we need a new function, mkdirat,
which I've just checked in to core
11 matches
Mail list logo
